I am trying to deploy a PHP Yii app to Orchestra (https://www.engineyard.com/products/orchestra/). The platform, like I think many cloud-based platform, doesn't allow write permissions.
I've managed to get around the 'runtime' directory that Yii requires by putting it in the system's tmp folder. However I'm stuck with the 'assets' folder. Yii requires a writable AND publicly accessible folder.
Is there a way around this?
Yii requires somewhere to put the files from within the core or modules to be publicly accessible.
If this isn't possible you might have to go through and manually grab each js/css file your going to want, place them in the folders required and use scriptMap to map these back or block them and include them yourself.
There's lots of documentation around Client Script which is what handles all this.
Related
We are deploying a new Laravel 5 installation and our client has said that they are unable to provide a writable directory on the web space that we are running on.
Is there any way that the storage folder can be by-passed when deploying the Laravel installation as I can only see logs and session based data that I am storing in MySQL anyway.
From Laravel official documentation
The storage directory contains compiled Blade templates, file based sessions, file caches, and other files generated by the framework. This folder is segregated into app, framework, and logs directories. The app directory may be used to store any files utilized by your application. The framework directory is used to store framework generated files and caches. Finally, the logs directory contains your application's log files.
You could prevent laravel from using the storage folder only if you modify the core files of the framework, because this is how laravel is set up to work.
I strongly advise you against that. Just migrate to another enviroment and get write permissions for that folder.
I know that this is not a proper solution, but it seems more harmful to your application structure and integrity to do core level modification.
By the way, you can move the storage to somewhere else... To the temp folder?
If that's a good opportunity for you, you can use:
$app->useStoragePath("/tmp/laravel_storage/");
Don't forget to build up the folder structure there (i.e. creating sessions, files, ...)
I've just started learning about HMVC in CodeIgniter.
So far I've been enjoying having modular controllers, but problems come when I wish to include javascript.
It seems to me that I'll have to include javascript file from the view instead of the widgets which isn't really good because I tend to forget which widgets has to come with which javascript file.
Anyone has a better way to do it?
Assets (css,js,images) you should place outside of application folder so you can access them directly.
Thus , you load them using base_url() to start with, and base_url() remains same from wherever you call it.
if you want to split assets in modules as well, perhaps make an assets folder, which further contains folders with module names, each containing css,js,images files. then use base_url()."/assets/module_name/js/script.js"
or something of the sort
As default, you cannot access files within your module folder as it was protected by .htaccess in applications folder.
To allow access in your assets/public folder within your module folder just add another .htaccess within the folder and add the following line.
Allow From All
I have just completed a fresh install of PyroCMS on a dev server and it appears that the system and addons folder reside above the document root folder within "public_html".
PyroCMS is based off of CodeIgniter and every time I did a CodeIgniter install it always had me place the system folder below the document root for security purposes. Shouldn't this be true with the PyroCMS install?
Modules require assets, which of course means HTTP access is required. We plan to eventually improve the Asset helper to GZIP/minify/combine everything and pass it through an "asset" controller, meaning images can be cached and resized, javascript can be squashed, etc.
Putting everything through a PHP file in this way means eventually you'll be able to have everything outside of the public folder, but for now you need direct access or you are entirely screwing with your chances of having a theme with images, css, javascript or icons.
Just don't tell Apache to serve PHP files as text/plain and you'll be absolutely fine. ;-)
I am developing a Joomla Component which will allow visitors to download a sound file (be it mp3, or wave, does not matter). Those files are managed in the admin interface and can be unpublished in there.
Therefore, it seems that placing them in the assets section is not an option, as it would make them accessible directly from the server. I want to avoid direct access and only serve them through my MVC structure (usnig RAW document type) after verifying that the requested file is published.
Are there any conventions on the placement of those files inside my component's directory structure?
My first idea is to create a folder inside the administrator/components/com_mycomponent and keep the files there. Do I need to restrict access to this new folder with a new .htaccess file, or is it already taken care of by Joomla with a global .htaccess?
you should place the files in the media directory. It is supported by the installer and is much better place. The logic is to have code in com_mycomponent for site and admin and both of those will share media (images/css/js), downloads, etc...
/media/com_mycomponent/
Restrictions are up to you.
Here is Joomla installation structure, http://docs.joomla.org/Components:xml_installfile
I’m new to CodeIgniter, I was wondering if it’s considered a good practice to restrict direct access to your view-files? Obviously they are going to contain a lot of php-code that relies on variables and what not passed to them from the controller, so the php-code could easily come up with an error if it’s directly accessed couldn’t it?
Bonus question: Why are the helpers, libraries, hooks etc. folders empty in the application folder?
Thanks for your time.
The main reason nobody bothers to restrict access to their view files is because they will either fatal error or show a useless page.
If people want to go to the effort of trying to work out your folder structure and file names, they will be rewarded with... absolutely nothing. You would have to write some really crazy code to make a view insecure.
If you REALLY want to secure them, go ahead.
At the top of your view, enter:
<?php if (!defined('BASEPATH')) exit('No direct script access allowed'); ?>
<h1>Whatever</h1>
I have never seen anyone restrict access to view files, but i dont see any reason why you wouldn't be able to do so. For better security you should really put your system and application folder below the web root and point the index.php back one directory to those folders. That way the possibility of someone directly accessing your files is slim to none.
As for why the folders are empty. The application folder is where you put YOUR code. The helper, libraries, and models folders in the system folder are filled with source code. The goal is to only put your code in application so when you upgrade to future versions of CodeIgniter your dont break any code or functionality you have implemented. You also can overload the codeigniter functions by doing what is says here...
http://codeigniter.com/user_guide/general/creating_libraries.html
and scroll down to "Extending Native Libraries"
user,
if you are on a shared host and they don't allow access to anything else than wwwroot folder, you can create a subfolder (name it "private") and write its .htaccess file to deny all requests to this subfolder. Then you can place the system and application folders of codeigniter in this subfolder and place your index.php folder in the regular location (changing the "system" and "application" variables inside index.php to correctly reflect the new paths) and that way all code is secure from direct access. :-)
edited:
About the folders question, its a scope thing. The helpers, libraries, hooks application folders are for application specific items. Maybe ones you custom create, or maybe ones downloaded from a third party. But the idea is that you have "system-wide" items and then you have "application-wide" items. Having application folders allows you to extend system-wide items to meet the specific application needs (see more # http://codeigniter.com/user_guide/general/creating_libraries.html). This doesn't make too much sense with one application, but if your installation has multiple applications, thats really where this comes in handy.