|
chorg has asked for the wisdom of the Perl Monks concerning the following question:
I'm looking for a way to control access to a series of web directories. I have no access to mod_perl, so I can't just make all the pages dynamic, and I don't want to use .htaccess unless I HAVE TO (not pretty enough for the client). I also do not want to make all the pages CGI driven, as only the access to that directory requires any logic. Any ideas? Anyone?
_______________________________________________
"Intelligence is a tool used achieve goals, however goals are not always chosen
wisely..." |
Re: CGI directory access control
by merlyn (Sage) on Feb 06, 2001 at 20:22 UTC
|
That's a "can't do it this way" specification. What is allowed? How are you expecting to authenticate the users, then authorize them? What mechanisms are you permitting?
If you just want to share a directory with some of your friends, give it an
obscure name and don't link to it. For real security, change the name of the directory daily.
If that's an insufficient solution, then please define what you do want to do, not what you don't want to do.
-- Randal L. Schwartz, Perl hacker | [reply] |
Re: CGI directory access control
by AgentM (Curate) on Feb 06, 2001 at 20:58 UTC
|
Though, as mentioned above, you have some pretty restrictive and rather silly requirements, I propose another solution- cookies or random URL IDs (remember, or is not mutually exclusive). Then, you could feed info about an otherwise unserved (via httpd) directory through a CGI to the person who enters the right password. Additionly, such a person would be potentially able to download files that would be otherwise inaccessible by httpd.
But be warned, this is a blatant security hole (you are simply circumventing everything that the httpd stands for) and I certainly must concur that using built-in security modules is the REAL solution. There are several modules that provide basic authentication to medium and maximum encryption solutions which are free and easy to install. Why not take a look at those instead?
AgentM Systems nor Nasca Enterprises nor
Bone::Easy nor Macperl is responsible for the
comments made by
AgentM. Remember, you can build any logical system with NOR.
| [reply] |
Re: CGI directory access control
by Fastolfe (Vicar) on Feb 06, 2001 at 20:32 UTC
|
Is your "no .htaccess" restriction against the use of an .htaccess file itself, or against HTTP authentication? If it's the former, I'd still highly recommend HTTP authentication to do this job, as it's the best solution. Anything else is going to either be insecure, or going to require a lot of work coding. Give us more information.
U: In case you are unaware of the distinction, a .htaccess file is just a way of specifying HTTP server configuration in a localized place. In almost all cases it is FAR better to specify these things in the main httpd.conf, as multiple levels of .htaccess files mean a lot of additional work for the server for every request. So if you are just anti-.htaccess but not necessarily anti-httpd.conf, I still highly recommend using HTTP authentication. | [reply] |
Re: CGI directory access control
by eg (Friar) on Feb 06, 2001 at 20:42 UTC
|
Given your (curious) requirements, the only other thing I can think of having a gateway page with a password form. If the form is filled out correctly, the user is redirected to the (ostensibly hidden and protected) directory. This is what sites that use Javascript to "protect" themselves do. I'm sure if you look on google you'll find plenty of examples. It's "security through obscurity" and not very effective.
I urge you to use .htaccess (server authentication) to restrict access to directories. It's clean and effective and does exactly what you want to do.
| [reply] |
Re: CGI directory access control
by gryphon (Abbot) on Feb 06, 2001 at 23:47 UTC
|
Greetings chorg,
If you can't use .htaccess files, and you don't want to use CGI, then I see it that you have only two options remaining:
- Use your web server's built-in security system.
- Use a combination of JavaScript and cookies.
The problem with #1 is that you're going to be at the mercy of your server. Most servers only offer HTTP authentication which looks and functions much like .htaccess files do. However, some really cool web servers allow you to massively customize the authentication process in order to make it "look nicer" for your client.
Option #2 is better in some ways. It lets you keep every page in HTML with no CGI and no server issues. It's somewhat annoying because it forces users to allow cookies, but IMHO, everyone should set cookies to auto-go.
With #2, you call a JavaScript file from your HTML document that checks for an authentication cookie. If no cookie exists, you boot the user to an authentication page. That page itself will probably have to be CGI based.
The real negative with this system is that a user could either turn off JavaScript or figure out how your authentication cookie is stored and create one for themselves.
-Gryphon.
| [reply] |
|
|
