Hey Everyone,
I am fairly certain that there must be an easy workaround to the issue I am experiencing but I might be blind to it. I am using Hunchentoot in the backend to handle a few things part of which is the session. Unfortuanetly it causes an error everytime I try to use the session I get a dump similar to this (I have cut it a bit to make more sense) 32SIGNAL
1. Couldn't write to #<SB-SYS:FD-STREAM for "standard error" {1002782181}>: Input/output error
31ERROR
1. SIMPLE-STREAM-ERROR
30SIMPLE-STREAM-PERROR
1. Couldn't write to ~s 2. #<FD-STREAM for "standard error" {1002782181}> 3. 5
23INTERPRET-FORMAT-LOGICAL-BLOCK
1. #&l t;SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {1000148D21}> 2. (WARNING Session secret is unbound. Using Lisp's RANDOM function to initialize it.) 3. (WARNING Session secret is unbound. Using Lisp's RANDOM function to initialize it.) 4. 5. NIL 6. (#<~S> : #<~3i> #<~:_> #<~A>) 7. 8. T
As you can see the problem is that it could not dump the warning on the standard output. My guess is that I should stop the warning but trying to do (setf hunchentoot:*log-lisp-warnings-p* nil) did not work with it.
Can anyone suggest what i am missing?
Mackram Raydan
Company: www.imagimate.com Website: www.trailoflight.net
"An invasion of armies can be resisted, but not an idea whose time has come." Victor Hugo
On Thu, Jan 28, 2010 at 6:54 PM, Arjan Wekking arjan@streamtech.nl wrote:
On 28 jan 2010, at 15:57, Patrick May wrote:
I don't think this is a Hunchentoot issue, but I thought I'd askhere 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 are-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 _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel