[hunchentoot-devel] Authorization data being cached

[Arjan Wekking]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4411 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100128/5daa6883/attachment.bin>