tbnl-devel February 2010

tbnl-devel@common-lisp.net

13 participants
11 discussions

[hunchentoot-devel] silly issue with session and Hunchentoot due to warning
by Mackram Raydan 01 Feb '10

01 Feb '10

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(a)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 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 > _______________________________________________ > tbnl-devel site list > tbnl-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel >

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel February 2010