(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

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.

Thanks for the book reference: http://modperl.com:9000/book/chapters/ch6.html. It will make for good bedtime reading.