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.
