Persistent sessions

[Ron Garret]

On Feb 14, 2014, at 2:31 AM, peter <p2.edoc at gmail.com> wrote:

> I find that I have the same requirement and would like not to 
> re-invent wheels so would much appreciate hearing any insights you 
> gained rg.

Turns out to be very easy.  HT sessions can be accessed and set via the generic function ht:session-db, which returns an alist.  The alist keys are fixnums and the values are opaque HT::SESSION objects.  To make a persistent session all you have to do is serialize and restore this alist.  All of the slots of an HT::SESSION are atoms, except for HT::SESSION-DATA, which is an alist, but it contains only values that you put there.  So serializing an HT::SESSION is not hard.

The challenging part for me turned out to be restoring Hunchentoot’s internal session state on restart, because HT assumes that there is an active request whenever a session is created:

? (make-instance 'ht::session)
> Error: Unbound variable: *REQUEST*

So you have to restore sessions using ALLOCATE-INSTANCE instead of MAKE-INSTANCE.  Other than that it is completely straightforward.  (I ended up writing a little general-purpose object serializer using the MOP.)

> For local hosting, I used a persistent global session-ID counter as a 
> patch (ensuring session-IDs can't overlap, but that's not acceptable 
> for cloud hosting.
> All I need really is persistence of the client's cookie validity, as 
> all state data I keep outside HT.

Not sure I understand this.  HT natively provides unique (per server) session id’s.  If you want to make session id’s unique across multiple servers that is a different problem than making sessions persistent.  But HT already has a hook for that: the generic function NEXT-SESSION-ID.  Is there a reason that doesn’t work for you?

rg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20140214/6bd64494/attachment.sig>