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.


Reply via email to