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.
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. Also, you mention that secure areas should "require a cookie". You've anticipated my next question... BUT!!! I'll start a new thread later, if I can't find answers in my reading. Again, thanks for your thoughts! Matt On Mon, Dec 20, 2010 at 3:46 AM, André Warnier <a...@ice-sa.com> wrote: > Hi. > > Without going into the details of your code, I believe that what you are > bumping against may be the very nature of HTTP. > > In your scheme, you need 2 consecutive interactions with the user, and the > second one needs to be able to "remember" what the first one was. > The basic logic of HTTP goes against that : each request/response cycle is > totally independent of the others, and there is no "memory" kept between two > transactions. > At least not by HTTP itself. Think that between your first interaction, and > the second, there may have been 1000 other request/response cycles happening > for other users. > > So the only way to do this, is by super-imposing some kind of "session" > mechanism, whereby the server can detect, on the second request, that there > has been a first one, and what its results were. > There are various such schemes, but the simplest mechanism for doing that is > probably via cookies. > Your first request/response should set a "step 1 cookie", which is detected > and read by the second request/response cycle, which then modifies that > cookie into a "step 2 cookie". > Your real application areas should then require the step 2 cookie for > authenticating a user and granting the resource. > > I think that trying to do this by playing with the "realm", which is > intimately linked to the URL requested by the browser, is going to lead you > into loops of logic. > > > > Matt Puumala wrote: >> [ snip ]
