Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

.htaccess and $ENV{

by nlafferty (Scribe)
on Aug 09, 2001 at 00:01 UTC ( #103201=perlquestion: print w/replies, xml ) Need Help??
nlafferty has asked for the wisdom of the Perl Monks concerning the following question:

I am looking for an easy way to add some sort of authentication to my program. I think that .htaccess and the $ENV{"REMOTE_USER"} variable is an easy way. My request is an example using this variable requiring valid login or fails to work. My main question is actually how .htaccess and this $ENV{"REMOTE_USER"} work together. Do i put and .htaccess file in my cgi-bin directory that the program is in? I have it semi-working, except it won't pop up with a login window when its in my cgi-bin. And the script still runs only i get no value for the variable i set equal to $ENV{"REMOTE_USER"}.


Replies are listed 'Best First'.
Re: .htaccess and $ENV{
by oakbox (Chaplain) on Aug 09, 2001 at 00:43 UTC
    If your user list is dynamic, your script needs a way to update .htpasswd (or whatever you call the password file). This is the section of my admin script that writes the .htpasswd file from a hash $user_hash{id}="password";

    # LOCATION OF PASSWORD FILE $PASSFILE="/usr/home/web_directory/protected_dir/.htpasswd"; open(WRT,">$PASSFILE"); foreach $id (keys %user_hash){ $pass2 = crypt($user_hash{$id}, "AB"); print WRT "$id:$pass2\n"; } close(WRT);

    You can change 'AB' in the crypt statement to any two letter combination!

    "If what I'm saying doesn't make sense, that's because sense cannot be made, it's something that must be sensed"-J.S. Hall

Re: .htaccess and $ENV{
by Trimbach (Curate) on Aug 09, 2001 at 01:23 UTC
    Just to add what has already been said: if you want to do .htaccess authentication then you have to have an .htaccess file in the cgi-bin folder that contains the cgi that you want to restrict access. If the cgi is fed information from an HTML form you probably want the folder the HTML file is in to also have a copy of the same .htaccess file. This will make users authenticate to the server before they even see the page they're supposed to fill it. You don't have to do this, but it isn't real stylin' to have the user fill out a form, press "Submit" and THEN have to authenticate.

    As mentioned above, you won't want to manipulate the $ENV{'REMOTE_USER'} directly, but you may want to read from it. I've used it in the past to give certain users certain "permissions" within my CGI. Kinda like this:

    if {$ENV{'REMOTE_USER'} eq "Cool Dude") { print p("You are a total stud!"); } else { print p("You are a luser."); }
    That kind of thing. At a minimum you must have your cgi directory protected by .htaccess or the $ENV{'REMOTE_USER'} will never be set.

    Gary Blackburn
    Trained Killer

Re: .htaccess and $ENV{
by sierrathedog04 (Hermit) on Aug 09, 2001 at 00:36 UTC
    Here is an example of a valid .htaccess file which we place in the directory that we wish to protect:

    AuthName "Security Solutions Center HelpDesk" AuthType Basic AuthUserFile /dkdkdkdke/.htpasswd AuthGroupFile /ej34l4l4tkgk/.htgroup <Limit GET POST> require group Xdwp </LIMIT>
    1. It sounds as if your Apache webserver may not have its basic authentication turned on. The book Apache Webserver for Dummies has a good chapter on how to configure your access.conf and other files to require basic authentication, which is what would cause the password window to popup. You want to make sure that Authtype is set to basic and that other parameters are also correct.
    2. Since basic authentication is not turned on there is no one logging in, so REMOTE_USER is empty.
    3. To do anything nonstandard use the CPAN modules htpasswd and htgroup. We use them to allow administrators to generate new users online.
    4. I cannot think of a time when you would need to manipulate REMOTE_USER directly. Basic authentication checks it for you.
    5. If you do need to access REMOTE_USER then access it using's param function, e.g., $q->param('REMOTE_USER').
      don't use <Limit GET POST>!! It's a leftover from NCSA days. It will actually limit authentication to only those methods, GET and POST. A malicious user can craft a request using another method, e.g. PUT, and that request will bypass your authentication. Folks, don't use LIMIT containers unless you know what you're doing.

        As echo says, you shouldn't use the Limit directives in this case - it really means "only limit the http request methods...".

        Just to clarify, all you have to do is turn this:

        <Limit GET POST> require group Xdwp </LIMIT>

        into this:

        require valid-user

        The first example means that to log in successfully, the username submitted has to match the password of that user (obviously), and also be in the group "Xdwp". In the second example, all that has to happen is that the username has to be in the password file.

        This has absolutely nothing to do with perl though, so I'd suggest having a look at <a href= docs on

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://103201]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (2)
As of 2019-01-19 22:28 GMT
Find Nodes?
    Voting Booth?
    After Perl5, I'm mostly interested in:

    Results (344 votes). Check out past polls.