views:

270

answers:

2

All,

I have the following Zend application structure:

helloworld
 - application
     - configs
     - controllers
     - models
     - layouts
 - include
 - library
 - public
    - design
       -- css
           -- site.css
       -- js
           -- global.js
       -- images
           -- siteheader.gif
           -- sitefooter.gif
    - .htaccess
    - index.php

My .htaccess file in public folder looks like this:

Options -MultiViews

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

My document root points to the "public" folder. Currently, if the user visits a directory level URL, (Ex: http://localhost/design or localhost/css) , my .htaccess file above make sure to show him the "Access Forbidden" page. But if he visits the file level URL, (Ex: http://localhost/design/css/site.css), it shows him the CSS file or the js file or PHP file..

How can I make sure to lock file level access for the above file types, if accessed directly from the URL? Since my application is JS intensive, I want to protect it from users looking at it.

Thanks

+6  A: 

You can't -- the browser has to be able to access it to display it and anything the browser can see, the user can see.

It may be possible to restrict access to browsers sending a referrer header, but that may break your site for some users whose browsers don't send a referrer and it doesn't help you as when a user tries to look at the source for the page, they will probably look at the copy which their browser has already downloaded for use in rendering the site rather than fetching a fresh copy.

Having said all that, you can use a script like YUI compresser to reduce the size of your JavaScript, helpfully also making it less readable :).

Andrew Aylett
A: 

This isn't possible. For example, if you have a JavaScript file

/js/seekrit.js

and you prevent it from being opened, it will also prevent opening by way of pages including it, as the browser will make a separate HTTP request (in the background) to the same page.

You could, however, use a hash of some sort to only allow authorised requests.

In other words, use server side for special stuff. Don't use JavaScript for seekrit stuff.

Delan Azabani