http://qs321.pair.com?node_id=200561

chuleto1 has asked for the wisdom of the Perl Monks concerning the following question:

Monks:
I am finishing up a PERL CGI (assignment for a computer science class. I am almost done but I am stuck on these two last requirements: On requirement 1) I have already saved the form contents to a file in my password protected area that uses the functionality of the .htaccess file.
On requirement 2) I know how to check the query string for "ACTION=DELETE" but I do not know how to incorporate the password protection logon of the .htaccess protected area as part of the condition for file delition. Does anyone know if the logon prompt returns an Environment Variable I might be able to use? (a boolean or integer)? Anyway I am a little lost as to how I could implement this without having my cgi script redirect to another cgi logon form when the query string is "ACTION=DELETE" and so on and so forth (Easy way). Any help or suggestions is apreciated.
-thanks

Replies are listed 'Best First'.
(jeffa) Re: CGI Advice
by jeffa (Bishop) on Sep 25, 2002 at 05:22 UTC
    "...but I do not know how to incorporate the password protection logon of the .htaccess protected area as part of the condition for file delition."

    Easy - you don't. You are dealing with two different levels of protection here: the first is your .htaccess stuff, which you have already set up. The second looks like hard coded values in your CGI script. Basically, any user that has an entry via .htaccess can add to the CSV file, but only one 'uber' user can delete it. That user will most likely have two identies - the first is some entry in the .htaccess file, and the second is 'fishbreath', which is queried from the CGI script, not the .htaccess mechanism. Here is some example code for you to ponder:

    use strict; use CGI qw(:standard); my $action = trim(param('ACTION')); my $user = trim(param('name')); my $pass = trim(param('password')); if ($action eq 'DELETE') { if ($user eq 'fishbreath' and $pass eq 'foobazz') { unlink 'path/to/csv.file'; } else { # permission denied! } } else { # do other stuff } sub trim { my $raw = shift; $raw =~ s/^\s*//g; # remove leading space $raw =~ s/\s*$//g; # remove trailing space return $raw; }
    The .htaccess will take care of letting users even access the CSV file - the CGI script will take care of letting the 'uber' user delete the CSV file. Good luck! :)

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    B--B--B--B--B--B--B--B--
    H---H---H---H---H---H---
    (the triplet paradiddle with high-hat)
    
Re: CGI Advice
by diotalevi (Canon) on Sep 25, 2002 at 05:01 UTC

    Yes, that's exactly what you do - provide a login form and if that's ok then do the action. Check out CGI::Application for help with this sort of thing.

Re: CGI Advice
by George_Sherston (Vicar) on Sep 25, 2002 at 11:18 UTC
    For requirement (2) you can get the submitted password user name from $ENV{REMOTE_USER}. Presumably if he got this far then this user is properly logged on, so you'd just check whether this particular user has delete rights. Or if you want him to submit his authentication a second time for security, you can get him to do that into a CGI form and then check validity using Apache::Htpasswd.

    edit 26/9/02 spartacus9 is quite right, and tactful to call it a 'minor' point - it is of course the user name you get and not the password - my bad.§ George Sherston
      minor clarification, but it is important to note that you cannot get the actual password from reading $ENV{REMOTE_USER}, or any other environment variable for that matter. $ENV{REMOTE_USER} will give you the username under which the user has authenticated, but not the password. That said, George Sherston is correct in that you can assume that if he got far enough to populate the REMOTE_USER variable that he is properly logged in.