I am likely to host an application on the shared host there I could not create virtual host or change something at apache.

Frequently applications with ZF appears like that:

  • root
    • public
      • index.php
      • .htaccess
    • application
    • library

I've sth. like this:

  • root
    • application
  • index.php
  • .htaccess

My code is incorporated in the application folder. But you will find several .ini and .xml files with sensitive information e.g. login names and passwords and so forth...

Basically give a .htaccess within the application folder with deny from all may be the information secure within the folder?

I authored relating to this lately at http://akrabat.com/zend-framework/zend-framework-on-a-shared-host/.

The fundamentals are:

Create a catalog.perl within the root folder:

define('RUNNING_FROM_ROOT', true);
include 'public/index.php';

Produce a .htaccess file within the root folder:

SetEnv APPLICATION_ENV production

RewriteEngine On
RewriteRule .* index.php 

Maybe set the applying_ENV to development although testing :)

Remember that when referencing static files the baseUrl() view assistant now indicates your root folder not your public/ folder.

Basically give a .htaccess within the application folder with deny all may be the information secure within the folder?

It isn't a perfect solution if the provider would alter the way .htaccess files are parsed (that they won't on the production machine, it would need to be considered a bad accident in the event that happened) however i guess it is the best you will get if there is no non-public directory.

If you're able to (I'm not sure whether ZF supports it), relabel the xml and ini files to .php. This way, even when the security is taken away, they'd get parsed as PHP files rather than being offered towards the public. It's a little paranoid but when it's possible with little hassle, not necessarily a bad idea.

You can preserve the typical directory structure on hosting that is shared. Just alter the document root with .htaccess. I actually do it such as this when confronted with a hosting that is shared:

RewriteEngine On

php_value upload_max_filesize 15M
php_value post_max_size 15M
php_value max_execution_time 200
php_value max_input_time 200
# Exclude some directories from URI rewriting
#RewriteRule ^(dir1|dir2|dir3) - [L]

RewriteRule ^\.htaccess$ - [F]

RewriteCond %{REQUEST_URI} =""
RewriteRule ^.*$ /public/index.php [NC,L]

RewriteCond %{REQUEST_URI} !^/public/.*$
RewriteRule ^(.*)$ /public/$1

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.*$ - [NC,L]

RewriteRule ^public/.*$ /public/index.php [NC,L]

Would you only have the public directory around the virtual host? Usually hosts provide you with access to a single directory above that, by which situation a far greater solution is always to produce a folder there into that you simply place your application. You would symlink the general public vhost directory in to the public directory of the application. Failing that, you can a minimum of keep the configuration files outdoors of the vhost's public directory, since easily tell ZF where they're situated.

Should you absolutely can't do either of those things then you'll have to make use of a file structure such as the one you recommended. Presuming your sensitive ini/XML files are to be used with Zend_Config, the component will also support PHP arrays for configuration (see example #1 at http://framework.zend.com/manual/en/zend.config.introduction.html ). This is a rather safer choice for you, as around the off chance your htaccess file wasn't working, your sensitive data would not be viewable as lengthy as PHP files remained as being parsed as PHP.