Jump to content

Directory restriction


Ninjakreborn

Recommended Posts

I want to restrict a directory where no-one can get into it from the browser.  Certain folder's however, when restricted using htaccess don't work.  Like my include's or other related folder's.  I was wondering if I go ahead and just put an index.php page in every directory, including CSS, atleast that will prevent them from going to the directory and getting a directory view of the folder along with server information.  I know how to stop them from going to htaccess, and php.ini and also how to restrict file's if needed, like important documentation.

Ok so images, I tried restrictiing it, no images appear on the page. So I can just create an index.php page in there that say's, You are not allowed to directly view this directory.

Then the include's, I tried it but don't remember the results.

The css pages where the same though they couldn't be pulled into the page.

Ok, in my folder I am using for my framework I have

master/ inside it there's
css, javascript, includes, config, portable and a few other folder's.
I wanted to atleast keep people from going to www.domainname.com/master and getting into a directory to see all the file's and structure.  So do I just put a protection file into each one.  also if I block off the whole folder, so they can't call specific pages.  I don't want them trying to pull up anything under
/master/config
because in there are all my functions, and system file.  ANy ideas?  At that point if they open my config file, and start feeding it variable's, who knows.  NEver thought about that, any advice?  Thanks?
Link to comment
Share on other sites

put:

[code]Options -Indexes[/code]

into an .htaccess file in each directory you want to "protect" (here, the /master/ and /master/config/ directories).  it won't send a friendly error message, but it will stop users from browsing the directory's contents if there's no index page.  alternatively you can add the <Directory> tags if you want to put this directly into your httpd.conf, in which case you don't need to place the file in each directory you wish to "protect."

if they're all going to be PHP and included files, you can put them above the webroot and reference it directly in the path.  you cannot do this with CSS, images and javascript however, as for HTML to access them, it needs a URL or their explicit contents.

to protect the CSS, images and javascript you need to do several things:  first, put them into a web-inaccessible directory (=> above the root).  second, since you can't source directly to these files (how do you specify the URL?), you have to source to a PHP file which will serve the file's contents.  i'm pretty sure that's overkill, though.

[b]EDIT:  was just clarifying Daniel's post, didn't see his reply before i posted.[/b]
Link to comment
Share on other sites

akitchen mentioned it, but i have a certain rule of thumb these days. if it needs protecting from access, put it below the web root. all my framework and other scripts go here. i actually do this with images too in the event that i want to restrict access to certain files. anything to be served directly to the user goes above the web root. once you get used to how to serve these files and include them, etc, you'll find it gives a little more peace of mind than just protecting a directory.
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.