[Dancer-users] Custom Session Handler issues
Brian E. Lozier
brian at massassi.com
Thu May 19 17:59:57 CEST 2011
On Thu, May 19, 2011 at 8:14 AM, David Precious <davidp at preshweb.co.uk> wrote:
> On Thursday 19 May 2011 15:32:02 Brian E. Lozier wrote:
>> I would be interested in this as well. The other problem that I
>> haven't had time to resolve yet is that using the built-in session
>> interface (no matter the plugin as far as I can tell) I can't set a
>> custom session timeout (based on form input, for example).
> You can control it with the session_expires config setting.
> This wasn't well documented in Dancer::Config; it is now.
I don't see much about sessions in Dancer::Config. It just tells you
you can enable sessions with the session engine. The most detail I
can find is here:
I think that's a global setting and not really what I'm talking about.
If I'm completely missing something please correct me.
This thread reminded me that I'd like to not have sessions enabled for
all accesses, only for logged in users. However, I have been using
one of the flash message plugins which require sessions for every user
anyway so it's not a big deal at this point. However, this issue
about sessions expiring keeps coming up for me. So pretend for a
moment that I do not want a session for every user, only for logged-in
users (thus, I would be creating the session).
There are two things I'd like to accomplish:
1. A log in page where user doesn't check a "remember me" box.
I would check user credentials, create a session, and send a cookie to
the user that expires when the browser closes. This is a "session
cookie" from the HTTP standpoint:
I would of course still keep a reasonable expire time on the server.
However, in this case it's really nice to expire not only the session
on the server but also the session cookie on the client so we don't
leave cookies hanging around forever on client machines.
2. A log in page where user DOES check a "remember me" box.
In this case I would check user credentials and then send a persistent
cookie that expires at some point in the far future (like a year).
I would also set their session on the server to persist for at that
amount of time.
The problem (that may not be a problem if I'm misunderstanding
something) is that I can't set the expire time of these session
cookies on a per-request basis. Dancer creates the session cookies
before I even have a chance to do anything. Dancer's session
interface is nice and simple but makes it impossible to
programmatically control the cookie expiration. It's set in stone (in
config) when the request starts. Even if I override it in one of my
routes, maybe it will work for that request, but next time the user
visits some other page the cookie will be reset to whatever is in
I have a couple of options:
1. Don't use dancer session interface for my login cookies/sessions.
This will allow me to control both the server and client side
2. Never expire client side cookies and when the user doesn't check
the box just expire the session sooner on the server side. If I set
the server expire too short, it will annoy users (because they're
still browsing in the same browser session and I expired them), but if
I set it too long, it will persist across browser closes. Users
expect that if they're logged into a site and they didn't check this
box, when they exit the browser they will be logged out. With a
persistent cookie it's impossible for me to detect whether the browser
was closed between requests.
I'm going to end up using option #1 because option #2 is cumbersome
and unreasonable (and can be insecure, for example, on public
terminals at libraries).
Dancer sessions are nice but the interface to them is too limited and
the fact that they are created all the time, instead of just when
needed, is problematic for me. I would like one that only creates the
session when session() is used and session() should take an argument
for client-side cookie expiration.
> David Precious <davidp at preshweb.co.uk> (bigpresh)
> "Programming is like sex. One mistake and you have to support
> it for the rest of your life". (Michael Sinz)
> Dancer-users mailing list
> Dancer-users at perldancer.org
More information about the Dancer-users