stringify-session calls encode-session-string which uses (session-start session) which is bound at session initialization to (get-universal-time).
session-verify tests validity by comparing the cookie session-string part to a new one made from a composite make from (encode-session-string id user-agent (real-remote-addr request) (session-start session))
but having just made a new session, that session-start component will not match. there's no way to get the original start time out of the cookie, so this part of the verification (together with the session expiry will have to be ignored.
as the session start time is encoded inside the cookie, it seems to be that it does have something to do with the cookie.
i suspect that you are using your model where you make the session-DB itself (the alist) persistent. i am not allowed to do this, hence why i am trying to i have to use the browser cookie, as that alone can be persistence (as in survive reboot or client or server).
At 10:05 AM -0800 14/2/14, Ron Garret wrote:
Huh??? The last click time is just a slot in the session object. It has nothing to do with the session ID or the cookie.
On Feb 14, 2014, at 9:44 AM, peter p2.edoc@gmail.com wrote:
Given that the cookie is the product of md5-hexing the raw composite cookie data (in encode-session-string), there's no way to get the initial click (creation) time of the session (which is needed in order to ascertain whether the session has expired (session-too-old-p)).
So presumably, like the session-ID, we'll need to carry the session start time externally (outside the md5-hexed part of the cookie).
Are we thinking along the same rg?
I'm puzzled that session persistence isn't a common requirement of hunchentoot.
-peter
Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail
Attachment converted: X:signature 1.asc ( / ) (0626022A)