Re: Set AuthName to prompt for sequential passwords

Matt Puumala wrote:
> Thank you for the reply!
> 
> I am with you 100%. There are plans for the session db, and the cookie
> format, all on the drawing boards, to get past "stateless http". But
> I'm trying to do it stepwise, to save my sanity.

Talking about HTTP authentication, that's a good plan.
Unfortunately sometimes difficult to follow, because HTTP authentication is full of twists 
and turns that don't usually let you do things stepwise.

> 
> So for now the question is: How do I actually prompt the user for the
> passwords? My reason for using Basic Auth and changing the realm is to
> make use of browsers' built-in popup auth mechanism. Is my solution of
> just authenticating twice naive? Is there a way to control that
> mechanism more manually (this is where my "change the AuthName in
> code" idea came from)? If not that, then...? Create an HTML form on
> the fly? (My gut says "eww" to that.) Any ideas you might have, including
> where to go to read more, are welcome.
> 
There is already plenty of stuff in the above paragraph to be answered.

What the browser displays in the title bar of its embedded authentication mechanism, is 
nothing else than the content of the "realm" of the "auth required" header that it 
receives back from the server.  So you could "trick" that by fabricating this header (and 
the 401 response) yourself, instead of letting Apache send it.
When the browser response will come back, it will have an "Authorization" header 
containing this same "realm" part that you sent, and since it is your authentication 
module catching this new request, you can deal with it too.
I am also quite sure that you could, with mod_perl, go and play games with Apache to 
change it's notion of the "realm" you are in.  But what I am not so sure of, are the 
unforeseen side-effects of doing that.

So I do believe that with your scheme, it may be better to go right away to your own login 
pages.  You can either create them on-the-fly, or have a template on disk with some 
pre-defined kind of markers which you would replace by whatever message you want to place 
there.  Which could even be things such as
<input name="hidden_param_1" type="hidden" value="%%%param_1%%%">
<input name="hidden_param_2" type="hidden" value="%%%param_2%%%">
...
which you find with a perl regexp and replace on the fly before sending the page to the 
user.  Then when the user re-posts that form (remember, maybe 30 minutes later), you can 
re-read these parameters to remember where you're at.  That may replace the cookie.
Provided that you do not give the opportunity for an ill-intentioned user to save the 
received form to disk, play with the hidden values, and then re-post the modified form and 
gain some advantage by doing so.

For more ideas, the Apache::AuthCookie module and the other Apache::Auth* on CPAN are a 
good start.

I think that the main thing to keep in mind, is that whenever you send back a response to 
the browser (whether it is a 401 or a 200 or whatever), the current request/response cycle 
is finished, done, forgotten, and the next request your module handles may be in 3 hours, 
come from another browser in another country, and be handled by another Apache child 
running another perl interpreter and another copy of your Auth module.
And if this new request happens to be a second one from a browser with which you 
interacted before, you have to be able to tell that only by the content of this new 
request. (Whether that is because it contains a cookie, or because it posts some special 
parameter from a form is a matter of choice, it is not essential in the overall logic).
And never trust what the browser sends.  It may not even be a browser.

Apache+mod_perl AAA is very powerful, and fun.  It can also quickly become very messy.