NPE in destroy-session; save-handler-session's response has nil at :session, but the session param is null

[Robert Campbell]

clear-session returns {:session nil} which I believe is added to the
request map. When, have this code on line 204 of session.clj:

session (if (contains? response :session)
(:session response)
(:session request))]

So session is set to nil, since response does contain :session, but it
has been cleared. We then call:

(when response
(save-handler-session repo request response session)

Which passes repo, request, response, nil, to save-handler-session:

(when (and (contains? response :session)
(nil? (response :session)))
(destroy-session repository session))

This when evaluates to true, passing destroy-session repo, nil, and finally

(defmethod destroy-session :memory
[repository session]
(dosync
(alter memory-sessions
dissoc (session :id))))

Which blows out with an NPE on dissoc (nil :id).

We somehow need to save the session id so that it can be dissoc from
memory-sessions, but we've already set it to nil, losing everything..

[James Reeves]

Hi Robert,

Sorry for the late reply. Google groups was broken for my account for
a while; I could view groups but was unable to post. However,
everything seems to be back to normal now.

This is a problem, but one that I don't think has an easy solution. In
retrospect, trying to create a common functional interface for
handling sessions may have been misguided. I may use a more procedural
approach for sessions in future.

- James

[Robert Campbell]

One alternative for some cases might be to just clear the session of
any user generated data, like this:

(defn clear-session-data
"Clear the session of any user generated pairs."
[request]
{:id (:id (:session request))
::expires-at (::expires-at (:session request))})

Of course your expiration keeps running, so you might have a case
where somebody logs in, only to have their session time out 10 seconds
later. I assume the with-session decorator could be tweaked to look
for a :forceRenew flag, but I'm not sure if this is a good approach.

> --
>
> You received this message because you are subscribed to the Google Groups "Compojure" group.
> To post to this group, send email to comp...@googlegroups.com.
> To unsubscribe from this group, send email to compojure+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/compojure?hl=en.
>
>
>

[Vagif Verdi]

On Nov 29, 6:28 am, James Reeves <weavejes...@googlemail.com> wrote:
> I may use a more procedural approach for sessions in future.

Is this a hint to an upcoming change in Compojure session middleware ?

I'd really love it to be the case. Working with session like with a
shared database is so much easier.

[James Reeves]

Yes... what I'll probably do is factor out session support into a
separate library. However, I may take a while to get round to that, so
if someone wants to have a go at creating a session library in the
meantime, I'd encourage the attempt.

I don't use sessions myself, so it's not something that has my
priority at the moment.

- James