Erroneous session-cookie setting behaviour in Dancer2
I created my own D2::Session::* class. I set session to something, with: session greeting => 'hello'; 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.
On Sun, 03 Mar 2013 02:29:47 +0200 Punter <punter@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. -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
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@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.
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@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@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@dancer.pm http://lists.preshweb.co.uk/**mailman/listinfo/dancer-users<http://lists.preshweb.co.uk/mailman/listinfo/dancer-users>
How about not having a session at all, if my previous session was deleted? 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@punter.gr <mailto:punter@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@punter.gr <mailto:punter@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@dancer.pm <mailto:dancer-users@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@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
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@punter.gr <mailto:punter@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@punter.gr <mailto:punter@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@dancer.pm <mailto:dancer-users@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@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
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@punter.gr <mailto:punter@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@punter.gr <mailto:punter@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@dancer.pm <mailto:dancer-users@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@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
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@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@punter.gr <mailto:punter@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@punter.gr <mailto:punter@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@dancer.pm <mailto:dancer-users@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@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
Furthermore, I just looked at my database logs and saw that a mere read-access of a session is enough to trigger a writing of the session data to the session store. This is wrong, as well. On 03/03/2013 07:44 PM, David Golden wrote:
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@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@punter.gr <mailto:punter@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@punter.gr <mailto:punter@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@dancer.pm <mailto:dancer-users@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@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Sun, 3 Mar 2013, Punter wrote:
What if a website's ethical policy is that it doesn't track users after they've logged-out?
I do not want to set a session cookie in that case.
How can it prove that to the users, if it installs a new cookie then?
I solved this problem by making 2 websites: - "static" no session - "dynamic" other hostname, other config.yml
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.
Sorry, it IS expected. It would be nice if one can start sending cookies only for some routes. -- Henk
On 03/03/2013 06:52 PM, Henk van Oers wrote:
On Sun, 3 Mar 2013, Punter wrote:
What if a website's ethical policy is that it doesn't track users after they've logged-out?
I do not want to set a session cookie in that case.
I, on the other hand, want to set a session cookie for when the user is logged in, and delete it (and not re-set it again) when the user logs out.
How can it prove that to the users, if it installs a new cookie then?
I solved this problem by making 2 websites: - "static" no session - "dynamic" other hostname, other config.yml
In my case, the same pages should appear on both sites, with tiny differences. It would not be practical to maintain two sets of pages with repeated elements for the cookie & no-cookie cases.
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.
Sorry, it IS expected.
It would be nice if one can start sending cookies only for some routes.
On Sun, 3 Mar 2013, Punter wrote:
On 03/03/2013 06:52 PM, Henk van Oers wrote: [look ma, no cookies :)]
I solved this problem by making 2 websites: - "static" no session - "dynamic" other hostname, other config.yml
In my case, the same pages should appear on both sites, with tiny differences. It would not be practical to maintain two sets of pages with repeated elements for the cookie & no-cookie cases.
I think https://metacpan.org/module/Wallflower can help. Best served as file, no Perl. get '/' => sub { template 'index'; }; is not required. Mmmm, Dancer behind the Wallpaper ? -- Henk
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.
So Rik, what's the point of getting a new empty session and cookie for it, instead of just a "negative" cookie (a set-cookie header with negative time) and no session at all to waste space on the db?
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.
So Rik, what's the point of getting a new empty session and cookie for it, instead of just a "negative" cookie (a set-cookie header with negative time)
Yeah you're right. It is probably better to put a "negative" cookie there if the session is non-existent/empty. I think I was going with a "that sounds like more code/more complexity than it's worth", but the privacy concerns (I've never cared about what cookies sites are throwing at me, for better or for worse) are fair enough I suppose.
and no session at all to waste space on the db? A smart session engine should probably not bother put any entries in the DB if the session is empty, but I take your point.
-- Rik Brown http://www.rikbrown.co.uk On Sunday, 3 March 2013 at 22:47, Punter wrote:
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.
So Rik, what's the point of getting a new empty session and cookie for it, instead of just a "negative" cookie (a set-cookie header with negative time) and no session at all to waste space on the db? _______________________________________________ dancer-users mailing list dancer-users@dancer.pm (mailto:dancer-users@dancer.pm) http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On 03/04/2013 01:01 AM, Rik Brown wrote:
Yeah you're right. It is probably better to put a "negative" cookie there if the session is non-existent/empty. I think I was going with a "that sounds like more code/more complexity than it's worth", but the privacy concerns (I've never cared about what cookies sites are throwing at me, for better or for worse) are fair enough I suppose.
Thanks. Are you one of Dancer2's core developers by the way?
There's no point putting in an expired cookie. Expired cookies should only be used to signal cookie deletion when a session is destroyed or no longer valid. The right answer is fixing the session keyword (and possibly the session accessor in Context) so that checking a session value when a session doesn't exist returns undef without creating a new session. It's a trivial patch. Just no one has written it yet. return unless context->has_session How about less complaining and more contributing? David On Mar 3, 2013 6:01 PM, "Rik Brown" <rik@rikbrown.co.uk> 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.
So Rik, what's the point of getting a new empty session and cookie for it, instead of just a "negative" cookie (a set-cookie header with negative time)
Yeah you're right. It is probably better to put a "negative" cookie there if the session is non-existent/empty. I think I was going with a "that sounds like more code/more complexity than it's worth", but the privacy concerns (I've never cared about what cookies sites are throwing at me, for better or for worse) are fair enough I suppose.
and no session at all to waste space on the db?
A smart session engine should probably not bother put any entries in the DB if the session is empty, but I take your point.
-- Rik Brown http://www.rikbrown.co.uk
On Sunday, 3 March 2013 at 22:47, Punter wrote:
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.
So Rik, what's the point of getting a new empty session and cookie for it, instead of just a "negative" cookie (a set-cookie header with negative time) and no session at all to waste space on the db? _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Sun, Mar 3, 2013 at 7:00 PM, David Golden <xdg@xdg.me> wrote:
It's a trivial patch. Just no one has written it yet.
In fact, it's so trivial I just did it once I got back to my computer: https://github.com/PerlDancer/Dancer2/commit/e34b07049a25926c3fb40b43bb42173... -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
It's a trivial patch. Just no one has written it yet. return unless context->has_session How about less complaining and more contributing?
Yikes, apologies, I wasn't trying to give off that vibe. I was trying to contribute by engaging the discussion around "the right way" it should work… as I haven't gone anywhere near the D2 code yet, so it didn't feel like it would have been trivial for me to patch it in right now.
In fact, it's so trivial I just did it once I got back to my computer:
Great :) -- Rik Brown http://www.rikbrown.co.uk/ On Monday, 4 March 2013 at 01:56, David Golden wrote:
On Sun, Mar 3, 2013 at 7:00 PM, David Golden <xdg@xdg.me (mailto:xdg@xdg.me)> wrote:
It's a trivial patch. Just no one has written it yet.
In fact, it's so trivial I just did it once I got back to my computer:
https://github.com/PerlDancer/Dancer2/commit/e34b07049a25926c3fb40b43bb42173...
-- David Golden <xdg@xdg.me (mailto:xdg@xdg.me)> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg _______________________________________________ dancer-users mailing list dancer-users@dancer.pm (mailto:dancer-users@dancer.pm) http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
participants (5)
-
David Golden -
David Precious -
Henk van Oers -
Punter -
Rik Brown