On Wed, Jul 23, 2003 at 02:37:30PM +0200, Fatih Gey wrote: > From: "Martin Wickman" <[EMAIL PROTECTED]>
[...] > > Nope. When the browser gets a 401 response from the server, it > > will (most likely) pop up a dialog asking the user for name and > > password. These credentials gets mangled into an Authorization > > header which gets sent with the next request once the user klicks > > OK in the dialog. Now, you can perform your authen-code as you > > like. Cookies and forms' got nothing to do with it, really. Read > > more here: http://www.faqs.org/rfcs/rfc2617.html > > > > Oh OK.., now i get it: In Basic Auth-Scheme, the Useragent -after > getting the required user and pass info from Client- resends his > Authorization-String in every Requestheader submitted to the > Server. Correct. > So the webserver have not to recognize an already authorized user, > as long as he's possible to authorize the user on every request. Correct. But you still have to do the authorization for each request. The nice thing is that one can delegate the authorization to the webserver, så that the application just have to check if REMOTE_USER is set or not. > So there's no way, to use an http-form instead of browser's ugly > authorization-box and perfrom the Basic Authorization (without > Cookies or taking an sessionkey with the url)? Correct, there is no official way. Except... there is one possibility. Most browser understands the url 'http://userid:[EMAIL PROTECTED]/protected/', and will parse that url and submit the credentials as if they were collected in the standard popup as usual. So, in fact, you _can_ do your authorization using a normal html form and then, upon valid credentials, create a such an url for the user to click/redirect. Messy, but it works. My personal opinion is that the "ugly" popup may indeed be plain and boring, but it is the only standard and resonably secure way of doing authentication. Btw, always use https or you will leak passwords all over the network.
