[hunchentoot-devel] Hunchentoot sessions

[Hans Hübner]

Hello Sebastian,

before putting effort into reviewing Hunchentoot's session handling
functionality, I would like to discuss your request:

Am I right in understanding that you are calling REMOVE-SESSION and
START-SESSION in one request, and that you're not seeing correct
results?  Or rather, are you calling REMOVE-SESSION and then REDIRECT
and don't see the results?  Is there a reason why you (seem to) need a
fresh session rather than just changing the session variable that your
application uses?

It would be helpful if you could formulate your problem in terms of a
bug report and include steps to reproduce the behavior.

Thanks,
Hans

On Sat, Jan 29, 2011 at 1:03 PM, Sebastian Tennant
<sebyte at smolny.plus.com> wrote:
> Hi all,
>
> I tried my hand at using sessions for the first time last year, and wrote the
> following notes in the process.
>
> ---8<------8<------8<------8<------8<------8<------8<------8<------8<---
>
>  ;;; Hunchentoot sessions are one-to-one associations between in-memory CLOS
>  ;;; objects and the (unique) value of any incoming session cookie (a cookie
>  ;;; with a particular name).  In short, whenever there's an incoming session
>  ;;; cookie, if there's a corresponding in-memory CLOS object then a session is
>  ;;; taking place and *SESSION* is automatically bound to the CLOS object.
>
>  ;;; Ending a session is therefore simply a case of deleting the in-memory CLOS
>  ;;; object, and starting a session is a case of arranging for a new session
>  ;;; cookie to be dispatched and creating a corresponding CLOS object.
>
>  ;;; Nothing is sent over HTTP until the execution of a handler is complete,
>  ;;; including cookies.  Imagine for a moment that you want to end the current
>  ;;; session and start a new one.  Somewhere near the beginning of your handler
>  ;;; you delete the CLOS object that represents the current session, arrange
>  ;;; for a new cookie to be dispatched and create a new matching CLOS object.
>  ;;; You then begin filling the new CLOS object with data until there comes a
>  ;;; point when you decide you want to perform a redirect, thus aborting the
>  ;;; execution of your handler before it's complete.
>
>  ;;; How should hunchentoot handle this situation?  If you perform the redirect
>  ;;; the new cookie will never be sent and the data in your CLOS object is
>  ;;; effectively lost.  Should hunchentoot somehow arrange for the same cookie
>  ;;; to be sent with the next reply?  Should it refuse to perform the redirect?
>
>  ;;; Hunchentoot's answer is to avoid this situation altogether by not adding
>  ;;; CLOS objects to the session database until their corresponding cookies
>  ;;; have actually been sent.  In practice this means that you can't delete the
>  ;;; current session and create a new one within the lifetime of a single
>  ;;; handler.
>
> ---8<------8<------8<------8<------8<------8<------8<------8<------8<---
>
> Are they accurate?  I'm not at all sure about the last three paragraphs.
>
> Seb
> --
> Emacs' AlsaPlayer - Music Without Jolts
> Lightweight, full-featured and mindful of your idyllic happiness.
> http://home.gna.org/eap
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>