Protecting private directories

**Jack** · 10-03-2004, 08:09 AM

I am trying to prevent visitors from accessing certain parts of my shop. The problem seems to be that I am using the OSCommerce shop. It has a directory named Includes and this is the one I want to protect. But the index page needs to access this directory when it builds the html code. If I Password Protect Includes, the whole site gets protected. I tried using Index Manager but had a problem with the back button not working. When I asked support about it, they said not to use it.

So, does anyone know how, if, I can protect directories such as this? If I just put a plain html index.htm file in there and have it display Access Denied, will that offer the same protection or is there a way around it?

Jack

**Vin DSL** · 10-03-2004, 04:35 PM

There are lots of different ways of doing this, but I cannot figure out exactly what you want to do (and not do). Maybe you can be more specific...

If all you want to do is keep lurkers out of this directory, simply make an empty file, call it 'index.html', and place it in that directory. When ppl try to access this directory, all they will get is a blank page, and there they will sit...

You can also make use of '.htaccess'. For instance, in some of my directories, I place a '.htaccess' file in them containing this:

Code:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([a-z0-9-]+\.)*lenon.com/ [NC]
RewriteCond %{HTTP_REFERER} !^http://([a-z0-9-]+\.)*66.227.17.133/ [NC]
RewriteCond %{HTTP_REFERER} !^http://([a-z0-9-]+\.)*69.73.147.61/ [NC]
RewriteRule ^.*$ http://www.lenon.com/index.php [L,R]

That makes it so you can access that directory from a link on my site, but not externally. If someone or something tries to access this directory from outside my site, it will redirect them to my homepage.

And, so forth, and so on. It just depends on what EXACTLY you want to do...

**Vin DSL** · 10-03-2004, 04:40 PM

Oh, BTW, the reason I have two IP's listed in that script is because I've had two different IP's since I've been here. For a while, during Jag's transition to 'American Registry for Internet Numbers', e.g. ARIN, both IP's were active...

**Jack** · 10-03-2004, 06:03 PM

I've tried the ways you suggested with limited success. First let me explain the problem in more detail. My test shop is at
http://excelsior.nocdirect.com/~ptcandy/shop/. The OSCommerce package loads files from the includes/ directory. I guess you could call these SSI files although I'm not sure if that is technically correct. The result is the same. If you visit the url http://excelsior.nocdirect.com/~ptcandy/shop/includes/, you can see all of the files there (maybe not now since I'm trying to get this to work). I don't want you to be able to look in that directory but the files in the root directory has to have access to them.

I tried placing an index.html file in the includes directory. It does prevent access if the url
http://excelsior.nocdirect.com/~ptcandy/shop/includes/ is used. But if you type in http://excelsior.nocdirect.com/~ptca...es/spiders.txt, the file is displayed.

I had asked Jag about using the .htaccess file at the beginning of all of this (yesterday morning - they are still working on it) and they said not to do it that way. That I need to use the Password Protection from CPanel.

I tried the .htaccess method. I thought I would prefer just locking it out and found an example on the net that said I could enter something like
User: some_name
Password: some_word
But when I use that I get an Internal Server Error message: "The server encountered an internal error or misconfiguration and was unable to complete your request."

Then I tried the redirects. I'm not familar with using this file but from the rule for redirects it said to use "rediret from to," so I put in redirect http://excelsior.nocdirect.com/~ptcandy/shop/includes/ http://excelsior.nocdirect.com/~ptcandy/shop/

But that didn't work. Failed with a 404 page.

Can someone help me out with the proper syntax? How do I protect against someone typing in the actual file name as above. I don't think it really matters, especially in the above case, but if I am going to do this I would prefer to do it completly.

Jack

**Vin DSL** · 10-03-2004, 06:44 PM

Hrm...

Well, let's keep it simple. Try putting this in the .htaccess file, in your root directory (/public_html):

Code:

<Directory /shop/includes>
AllowOverride None
Deny From All
</Directory>

If that doesn't work, try putting this in a .htaccess file, in your /includes directory instead:

Code:

<Files *>
Deny From All
</Files>

**Jack** · 10-04-2004, 01:59 PM

I tried them both and got the same Internal Server Error I mentioned before. The whole site became unaccessible.

Jack

**Spathiphyllum** · 10-04-2004, 04:48 PM

Originally Posted by Jack

...My test shop is at
http://excelsior.nocdirect.com/~ptcandy/shop/...

A little off topic here but while you are testing a site that will sell items, might I suggest you work with SSL first? People will more than likely NOT purchase anything online without feeling some sense of security. That little locked box in the bottom of the browser provides an enormous sense of security even though it is not a guarantee of any.

I'd advise working with https:// as your url prefix protocol indicator while you're setting things up. You'll need this capacity in the future and might as well start right from the beginning.

On topic... I don't work with php but what does the program do with the "/includes" files? Are they templates that are parsed with data added to them before they are pushed to the browser or are they complete, final GUI frontend pages with form data to be added by the user? And what are the permissions required by these files? 0777? 0755? 0711? You might be able to secure things a bit more by restricting permissions.

**Jack** · 10-04-2004, 06:42 PM

I do have a certificate. This is a test site.

Yes, the files are templates. Some of them need to have read-only status while others require full permission.

Jack

**Vin DSL** · 10-04-2004, 11:45 PM

Originally Posted by Jack

I tried them both and got the same Internal Server Error I mentioned before. The whole site became unaccessible.

Jack

Yeah, it's hard to get these things to work right until you get everything setup with a domain name, an IP, and all that rot. Even then, it can be trying.

LoL! I started playing around with various .htaccess files on my site last night, and everything looked fine until I cleared my cache. Then, I didn't have any pictures. Hahahaha! Then, 403's started popping up all over the place, for myself and everyone on my site.

The good thing and bad thing about .htaccess is the one in the root affects the ones in the trunk, and the ones in the forks, and so forth, and so on, down the line. So, you gotta be careful about what you change.

My .htaccess file in the root is 15k, so it's a 'can of worms', for sure...

**jason** · 10-05-2004, 08:27 AM

Make sure that you have your permissions et to 644 on the .htaccess file(s). If Apache can't read it/them but it knows they are there then it will cause your entire site to show as a "500" server error.

Second, I don't know the cart software you are using or how well it is written, but perhaps somewhere in a config file there is an entry where you can set the path to the includes directory (as opposed to it being hard-coded into every call to an include file). Most well-writen packages these days are set up this way. Then, as long as that includes directory doesn't contain any files that will be called directly by the browser (such as JavaScript files, stylesheets, or images), you can move the directory out of your public_html directory completely. (Set the config path to the absolute path of the directory, which would be something like /home/username/includes or /home/username/cartincludes if you want to keep it separate from other possible future setups.) With it outside of the public_html directory it will still be accessable to all of the server-side scripts that need to use it, but it will be out of the realm of what Apache will let a browser see--and therefore away from prying eyes.

--Jason

**Jack** · 10-05-2004, 01:50 PM

Thanks for everyones help. I have it working - sortof. Jaguar first told me to use Index Manager and no other way. Then they said not to use Index Manager. That I should be using Password Protection. That didn't work and they said I should be using Index Manager. Argh!!! Today they said using .htaccess is fine. Somehow (I didn't load it), the .htaccess file I have in there now just has Options All -Indexes in it. From the way I am reading the explanation of the options, this should be doing the opposite (letting everyone in, not keeping them out). The Internal Server error turned out to be becuase I did not have a 403.shtml file so it was reporting that as an error.

I now have a mixed up pile of settings. Some directories have the settings from Index Manager and some have .htaccess files in them. It appears to be working so I'm going to leave it alone for a while and start back with a fresh start. I know it will work, it is just a matter of finding out the proper way now. So, again, thanks for the replies. I appreciate the help.

Jack

**Spathiphyllum** · 10-05-2004, 03:26 PM

See Apache Options Directives.

Code:

Options All

# All [resets all Options in the directory to "enable"
# except for MultiViews]
#
# If All is excluded, the list of Options will be inherited
# by the previous .htaccess Options parameters,
# if any.

For your /includes directory, you'll probably want one of the following in your .htaccess file which assumes that no preceding parent directory already includes these Options. The "+" sign in front of the Option parameter is optional. Also, this is the more secure implementation of allowing SSI.

Code:

#########
#Option 1
Options IncludesNOEXEC

# Completely resets Options to new parameters, in this
# case a more secure SSI implementation, and ignores
# any previous Options in any parent directory. You may
# need to use "Includes" instead of "IncludesNOEXEC"
# if your script makes system calls to shell apps.

#########
#Option 2
Options +IncludesNOEXEC -Indexes

# Inherits Options from previous directories (rather than
# overwriting them anew), adds SSI capability and
# denies indexed listing of files.
# You'll need to add the +/- for all Option parameters
# for this type of merging to be successful.

Unless you use lots of SSI throughout your site. it's probably best not to enable it in the webroot .htaccess file and just turn it on in the includes template directory or in other directories that require SSI parsing (i.e. *.shtml files by default). You can SSI parse any file if you define the MIME type in your server config/.htaccess files. But that is another lesson.

**Jack** · 10-05-2004, 06:02 PM

Thanks for the code. I tried sticking it in there to see what would happen but apparently Jag has changed some setting because all of my directories are protected now. I haven't touched a few of them in weeks so I know I didn't do it. They didn't bother mentioning to me what they did so I have no way of knowing how to back it out. I guess I better leave well enough alone. Some of the files that I wanted protected are still accessible but I will just have to live with that. Thanks again.

Jack

**Vin DSL** · 10-06-2004, 01:13 AM

You know, reading through this thread, it seems like you are straddling the line, with a foot in each camp...

I've been doing this stuff a long time. Originally, my BBS was done in ASCII, coded in BASIC, if you know what that is. Then, I graduated to HTML, the next big milestone. I played around with this 'n' that and settled on Perl/CGI. I dabbled in Python, and so forth. Now, it's PHP, blah, blah, blah. There was a lot of stuff in between, but who cares. I don't even want to think about all the things I tried. It's depressing! I'm simply trying to make a point - I've been around the track a few times, as I'm sure you have...

As soon as I 'heard' SSI, I knew where you were coming from. I judge that you are somewhere between Perl and PHP, in your walk through computerdom.

If this is the case, all I can tell you is to forget everything you've known in the past and make the leap to PHP. Jump off the cliff. Devote all your time to it. All those other relics are crap! PHP with a little HTML and Javascript is the way of the future. As a matter of fact, if you haven't figured it out already, PHP is a direct replacement for SSI, e.g. PHP is SSI done right - and probably the thing that's driving you to it. That's where PHP all started, but now it's a thing onto itself. You can do anything and everything with PHP! HTML and Java are simply crutches for retards and lazy ppl like myself. That is, it's easier to inject a little 'old school' code, here 'n' there, than to do it right, in 100% PHP.

Anyway, if I have you pegged all wrong, forgive me, but that's the way I see your situation, based solely on what I've read in this thread.

**Spathiphyllum** · 10-06-2004, 03:50 AM

Jack,

Or you could focus on learning just the things to get the job done. I don't know how much developing you are interested in doing and whether you are even interested in being a webmaster. Maybe you are more interested in just installing and tweaking pre-packaged productions so that you can focus on just the things that truly interest you.

The thing about languages, and I'm sure you know this, is that they are moving targets. What is the language du juor is obsolete junk, in some people's opinion, tomorrow. I wouldn't get too wed to any particular language since new flavors and implementations are always coming down the pike and you won't always get to pick and choose the one you want. The industry will change the environment for you. It might be more appropriate to just continue with the motions of learning a language, any language, to acquire the fundamentals of programming common to the discipline. Once you've conquered that, most of the battle is won and you can pick and choose the right tool for the right time.

If programming really isn't your bag, then just modify what you can acquire and hire out that which you cannot or do not want to tackle... and then proceed to focus on the site content that interests you. Afterall, there are only so many hours in a day. Just another opinion.

LinkBack

Thread Tools

Display

Protecting private directories

Bookmarks

Bookmarks

Posting Permissions