On Thu, Jan 28, 2010 at 15:57, Patrick May patrick.may@mac.com wrote:

I don't think this is a Hunchentoot issue, but I thought I'd ask here first.  I've noticed that Safari seems to cache the basic authorization username and password, so that even if I call (remove-session *session*) on the server side, Safari just reloads the page.

AFAIK, every browser does this. It's the only way HTTP Basic auth can work without being terribly annoying to the user.

Am I interpreting the behavior correctly?  If so, how do I force a re-authorization?

To "log out" the user, you need to return a 401 Unauthorized status (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html), which will prompt the browser to display the user/password dialog box again. If the user presses Cancel enough times, they'll finally be logged out.

It's terribly convoluted, but that's Basic auth for you /-:

Cheers,

On 28 jan 2010, at 15:57, Patrick May wrote:

I don't think this is a Hunchentoot issue, but I thought I'd ask here first. I've noticed that Safari seems to cache the basic authorization username and password, so that even if I call (remove- session *session*) on the server side, Safari just reloads the page.

As far as I know, Hunchentoot sessions have nothing to do with HTTP basic authentication, of which Safari can indeed store the credentials in the OS X Keychain (other browsers like Firefox or Chrome also allow you to 'save your username and password' somewhere).

All browsers actually 'cache' HTTP authentication credentials one way or another between HTTP requests and usually forget them when you close the window and/or tab that was authenticated [1]. This is not the same as storing them in the Keychain but just part of how a HTTP authentication 'session' works in browsers.

Standard Hunchentoot sessions have nothing to do with HTTP authentication unless you've re-implemented them to use HTTP authentication credentials as session identifiers somehow (which would be an interesting approach but that's not really relevant right now).

Am I interpreting the behavior correctly? If so, how do I force a re-authorization?

With HTTP authentication, the simple anser is that you can't. Logging in and out is under the HTTP client's control (where it in my opinion should be). Unfortunately there's no good UI in browsers yet to gracefully log in and out with HTTP authentication. Heck, you can't even see *if* your browser is supplying any HTTP credentials without inspecting your own HTTP requests.

Theoretically, you can do something like:

(setf (return-code*) +http-authentication-required+)

Which basically means that your webserver is telling the HTTP client that whatever it supplied as credentials in the current request is not accepted anymore (401 Unauthorized) and that it, in other words, should supply other credentials. Some browsers will then clear the 'cached' credentials and ask the user to supply new ones.

This means that in browsers that do not store credentials, you will be presented with a new 'please enter your username and password' dialog again, right after logging out, and there's no way around this. I think Safari, in this case, simply fetches them from the Keychain again and silently 'logs in' again without the user even noticing, but I'm not entirely sure about this.

Either way, it's not a real solution.

One thing that might work is to embed the Hunchentoot session ID into the basic authentication 'realm', in which case (remove-session *session*) actually works. But, by doing this, you effectively break the whole 'store this username and password in my keychain' feature of Safari and similar 'remember this username and password' features of all browsers, because the browsers will store them along with the realm and when the realm changes, it cannot reuse these stored credentials.

The other way is to use cookie or URL based session and store the authentication status in the server. This is where the Hunchentoot session would come in and in this case you would probably need to build a simple log-in HTML form, although it's possible to use HTTP authentication to 'authenticate' the session as well and offer both a public login form and HTTP authentication when directly accessing protected resources and still have a 'log out' option that simply destroys or de-authenticates the session server-side.

I hope this all makes some sense :]

-Arjan

[1] http://en.wikipedia.org/wiki/Basic_access_authentication