The most common problems regarding htaccess files and CGI are:
- Not having the htaccess file restrict the CGI's location for the same "authentication realm", and
- "restricting the restrictions". (You should not have a <limit GET>-like line anywhere in your htaccess file. If you do, you cargo-culted it from a bad source.)
Check both of those first.
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply. | [reply]
[d/l] |
| [reply] |
(whispers) I think what merlyn means is that in order for $ENV{ REMOTE_USER } to be provided to a cgi script, it must itself be in a place that requires authentication, and that authentication must be with reference to the same 'authentication realm' as your protected files unless you want people to have to log in twice. In other words, the lines in the htaccess file that start 'AuthName' must match, as well as the passwd file.
as for the limit clause, I think he means that the require valid-user line is fine by itself, and sources which suggest otherwise are not to be relied upon. but I'm not sure that's all he means, or anything.
but anyway, you can't use a cgi script to _set_ REMOTE_USER, or not in a useful way. It's actually the browser that remembers that login information, once it has been asked for it as part of the give-me-a-page handshake with the server, and passed the question on to the user. It conceals the fact that it's presenting the username and password with every relevant url request after that. So it only works the other way round: log into apache, access that identity in cgi script, log out if you can...
if you really want to avoid the standard pop-ups, there's no alternative to proper session tracking. you can either roll some cgi to do it, with or without cookies and CGI::Session, or use apache's mod_usertrack and get it from the usual logfiles.
updated yes, this is the less muddy version
| [reply]
[d/l] |
The problem I'm would like to solve is authenticating via a CGI script (instead of the popup) and then track the user via something like REMOTE_USER.
Oh! Sorry, not possible. The user info and popup is controlled via the browser-server connection, before a CGI takes effect. (You can control this interaction via a mod_perl handler, but you options are still limited because so much happens at the browser level)
You could, in theory, have a .htaccess protected area, with a CGI login script that forwarded you to http://user:password@domain/path/file.html that would bypass the "popup", and include a custom 403 (forbidden) page that sends you to that script should someone try to come in by another method, but that's pretty clunky, and I'm pretty sure (not positive) that that's a netscape convention and not a universal one (though I think IE also supports it).
There is a reason most places eventually go to sessions :) Even if .htaccess control is elegant, they want the script interface, and they aren't compatible.
Update: The eagle book has a good section on what the server/browser are doing behind the scenes for authentication/authorization. It won't help you do what your trying (I've tried it myself), but it does explain what's happening and lets you understand why it doesn't work.
Also added the bit about 403 above.
| [reply] |
$ENV{REMOTE_USER} has worked fine for me in the past using .htaccess authentication. Can you offer some detail on your setup?
Update: Comprehension dawned with more detail, see upthread, which makes this comment useless except to confirm for random browsers that $ENV{REMOTE_USER} works as advertised with .htaccess.
| [reply]
[d/l]
[select] |