SESSION_EXPIRE_AT_BROWSER_CLOSE

[ADEWALE ADISA]

Good day;
Please i need help on the issues am facing on SESSION_EXPIRE_AT_BROWSER_CLOSE django settings.py. In my setting file i have:

SESSION_EXPIRE_AT_BROWSER_CLOSE = True

but unfortunately, whenever my users close there browsers and open it again, they are login automatically, which shows that the session did not expire.
Am facing this issue on all browers.
On chrome, when i went to the settings and manually choose to expire cookies, the  SESSION_EXPIRE_AT_BROWSER_CLOSE worked.
In deployed application, i can not be asking my users to be changing cookies setting in their browsers.
Please how can i achieve session expire after closing browser irrespective of user browser settings. Or if there is javasctipt snippet i can use to control this.

Thanks in advance.
soliu - fxSoftlogix

[James Bennett]

Make sure you're not looking at users who already had a session cookie set before you changed the setting. Existing cookies might not get immediately rewritten to have the shorter expiration.

[ADEWALE ADISA]

Thanks Mr James for the urgent reply.
Even when the server and the user pc are restarted after the setting, the situation is the same.
from the django docs; there is a section that goes :

Note

Some browsers (Chrome, for example) provide settings that allow users to continue browsing sessions after closing and re-opening the browser. In some cases, this can interfere with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting and prevent sessions from expiring on browser close. Please be aware of this while testing Django applications which have the SESSION_EXPIRE_AT_BROWSER_CLOSE setting enabled.

Maybe this is what is causing the issue. but i just think that people must have a way of going around this problem.

On Jan 22, 2017 9:41 AM, "James Bennett" <ubern...@gmail.com> wrote:

Make sure you're not looking at users who already had a session cookie set before you changed the setting. Existing cookies might not get immediately rewritten to have the shorter expiration.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAL13Cg-ycUN1cjiy_sbtdvRYa0sF4KMVHUK%2B%2BTipC1GCy0XWww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[ADEWALE ADISA]

thanks again Mr James.
am able to solve the problem now by running the management command "python manage.py clearsessions".
This pratically delete all the session stored on the django session database.

so SESSION_EXPIRE_AT_BROWSER_CLOSE behave as it should now.

On Jan 22, 2017 9:41 AM, "James Bennett" <ubern...@gmail.com> wrote:

Make sure you're not looking at users who already had a session cookie set before you changed the setting. Existing cookies might not get immediately rewritten to have the shorter expiration.

--

[M. Farhan Zia]

Im facing the same problem, How did you solve this problem?

[Bill Freeman]

Once there was no such thing as a cookie that expired at browser close.  Note that such must be implemented by the user agent (browser), since that's the only thing that knows if it has been closed.  (And, in fact, if you want it to be closed if the browser crashes, or if it is hard killed by the OS, or if the machine crashes, it doesn't get an opportunity to delete cookies.  Probably this is implemented at start up, when it can toss anything in the cookie store marked as close at end of browser session.  Cookies in RAM only is another approach, but there can be security exploits through having cookies push the size of process RAM.)  You would have to check whether the user agent (as claimed) supports this, since not all browsers (I'll bet) support the feature, and choose a different mechanism otherwise.  Probably best to just use that other mechanism.

One approach comes to mind.  Have JavaScript implementing a heart beat poll, and have the cookie invalidated on the Django side if the last access, poll or normal, was "too long' ago.  Two issues with involve what constitutes "too long".  Sometimes people have bad connections, and "too long" may elapse during their network latency of the moment.  And if "too long" is too long,  you can easily close and restart the browser before it elapses.

Another that may or may not be possible in all user agents is to access the timestamp at which the browser was started and include that with each request (possibly by having the JavaScript that runs when the page load modify the cooking to include that timestamp.  Then Django session code would have to consider a non-matching cookie invalid, but accept that timestamp when accepting a log in.

This has long been a tough problem.  Further, I'm not sure that you are doing your users any favors by training them to believe that closing the browser logs them out.  There will be plenty of sites where this doesn't work.

--

You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/add560a7-21ee-4971-98fd-8e8dc66c6b13%40googlegroups.com.