[dancer-users] Erroneous session-cookie setting behaviour in Dancer2

David Golden xdg at xdg.me
Sun Mar 3 17:44:43 GMT 2013


context->destroy_session

There is a "bug" in the sense that sessions are instantiated as soon
as you request them.  So the mere fact that you check
session("logged_in") or whatever creates a new session if none exists.

This is issue #155 in github.  Ideally sessions would only be
instantiated when a value is set.

David

On Sun, Mar 3, 2013 at 11:49 AM, Punter <punter at punter.gr> wrote:
> Plus there's no session->destroy method, so how can I log out a user
> properly?
>
>
>
> On 03/03/2013 06:02 PM, Punter wrote:
>>
>> What if a website's ethical policy is that it doesn't track users after
>> they've logged-out?
>>
>> How can it prove that to the users, if it installs a new cookie then?
>>
>>
>> On 03/03/2013 05:55 PM, Rik Brown wrote:
>>>
>>> That sounds like it's working correctly. You got a new empty session and
>>> a cookie for it. I don't think it's expected that you won't get a cookie
>>> if your session is empty.
>>>
>>> Cheers,
>>> Rik
>>>
>>> Sent from my phone.
>>>
>>> On 3 Mar 2013 15:53, "Punter" <punter at punter.gr
>>> <mailto:punter at punter.gr>> wrote:
>>>
>>>     Ok.
>>>
>>>     I went to the Database and deleted the session for which I had a
>>>     cookie, and next time I loaded a page I got ANOTHER cookie, for a
>>>     new (empty) session.
>>>
>>>     This, I believe, is a bug.
>>>
>>>     On 03/03/2013 01:42 PM, David Precious wrote:
>>>
>>>         On Sun, 03 Mar 2013 02:29:47 +0200
>>>         Punter <punter at punter.gr <mailto:punter at punter.gr>> wrote:
>>>
>>>             Now whenever I do a page any view, I get a "this website
>>>             wants to set
>>>             a cookie" message
>>>
>>>             It shouldn't be like that. If cookie values don't change,
>>>             then they
>>>             should only be set once.
>>>
>>>
>>>         Except that, if you don't send the Set-Cookie header again each
>>>         time,
>>>         the cookie's expiration can't be updated - most people want a
>>>         session
>>>         expiry to be extended with each request, so it times out the
>>> right
>>>         amount of time after the last request, rather than the last time
>>> the
>>>         session data was updated.
>>>
>>>         I think this is quite common and correct behaviour.
>>>
>>>
>>>     _________________________________________________
>>>     dancer-users mailing list
>>>     dancer-users at dancer.pm <mailto:dancer-users at dancer.pm>
>>>     http://lists.preshweb.co.uk/__mailman/listinfo/dancer-users
>>> <http://lists.preshweb.co.uk/mailman/listinfo/dancer-users>
>>>
>>>
>>>
>>> _______________________________________________
>>> dancer-users mailing list
>>> dancer-users at dancer.pm
>>> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
>>>
>
> _______________________________________________
> dancer-users mailing list
> dancer-users at dancer.pm
> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users



-- 
David Golden <xdg at xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg


More information about the dancer-users mailing list