[hunchentoot-devel] silly issue with session and Hunchentoot due to warning

[Mackram Raydan]

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 at 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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100201/b5d6c939/attachment.html>