Hello. I recognize this isn't a super helpful issue to post. I'm just looking for some ideas on what might be causing the reported issue, or how to debug it. Thank you!
Problem/Motivation
A user logs in with persistent login (remember me checked). After some time (or a browser close?) the user may appear logged out. They can click the "Log In" link in the site's header to re-establish their session. They do not have to supply credentials. They are logged in automatically and immediately. Unconfirmed note: the act of going to any uncached page likely re-establishes the user's session.
Steps to reproduce
Unfortunately I cannot reproduce. I'm hearing this report from several of our site's users. Any thoughts on how I could get this to happen? I've tried messing with (editing/deleting) both cookies in my browser. I've tried clearing caches. I've tried adjusting the expiration time (currently "0"). I cannot get the issue to happen.
I have the correct cookie settings configured in my Platform.sh routes file.
Comments
Comment #2
agileadamI can simulate the Drupal session expiring by deleting the Drupal session from the DB.
I recognize this isn't a real world series of events, but it is a reliable way to replicate the experience.
Pattern 1:
- I log in with "Remember me" checked
- I see in the database that I get a Drupal session and a persistent login token
- I load the homepage
- I manually delete the corresponding row in the DB session table
- I click the reload button in my browser (or hit ⌘R) or I click into the address bar and hit ENTER (same result either way)
- The page loads and I appear logged out (no "My Account" link, "Log in" link instead of "Log out" etc.)
- I reload the page again or click an internal link
- The page loads and I appear logged in now
This is the issue. People will go away for a while (days?) and come back to the site from the same computer. They then try to visit the site or refresh it if it's already open, and they appear to be logged out. As soon as they click the "Log in" link (or any other link, or refresh again) they'll be logged in then.
Pattern 2:
- I log in with "Remember me" checked
- I see in the database that I get a Drupal session and a persistent login token
- I load the homepage
- I manually delete the corresponding row in the DB session table
- I click any internal link on the page
- The page loads and I appear logged in immediately
QUESTION: What is different about clicking a link vs reloading/visiting the page?
The user_login_finalize() call in \Drupal\persistent_login\EventSubscriber\TokenHandler::loadTokenOnRequestEvent doesn't execute the first time I reload/revisit the page. It does execute immediately if I click a link.
Comment #3
agileadamAnother piece of info: It seems like the culprit, at least for my site, is when there is a SSESS Drupal cookie in the browser, but the session no longer exists in Drupal's sessions table. If I remove the session from the DB and remove the browser's session cookie, everything works as expected (no matter what I do I end up logged back in immediately).
If I leave the browser SSESS session cookie in place and the session is removed from the DB, it takes multiple page refreshes for the user to be logged in.
The associated code in \Drupal\persistent_login\EventSubscriber\TokenHandler::loadTokenOnRequestEvent is:
if (!$this->sessionConfiguration->hasSession($request)) {So, what I'm wondering is... is it normal for a Drupal session record (in the DB) to go away (be removed from the db) before a user's browser session cookie expires? Is there something weird with my configuration maybe?
Comment #4
agileadamMight this be causing the browser cookie to hang around longer than the session in the DB?
I could see someone leaving work on a Friday (browser stays open), then coming back to their desk on Monday and refreshing the page. \Drupal\persistent_login\EventSubscriber\TokenHandler::loadTokenOnRequestEvent would still think there is a session (hasSession would see the SSESS cookie) but garbage collection on the server would've removed the session from the DB.
Comment #5
agileadamLast post for now... I figure more info is better than less. It seems like this problem is specific to my Drupal front page.
My "Default front page" setting points to a `/home` node (literally just a contentless basic page node; all content placed via blocks for this particular path).
Might this be caching-related?
Comment #6
gappleI can see the potential issue that PL calling
sessionConfiguration->hasSession()only checks that the session cookie exists - if the session start process doesn't remove the session cookie from the request's cookie bag when it is unable to load it from the database, then PL could incorrectly assume that a session exists and is started, and not act when it should.TokenHandlermay need to callSessionManager::isStarted()instead to properly check that a valid session has been started.The module's current functional test deletes the session cookie from the browser (simulating the cookie being expired & cleaned up), and reloads a page. I don't think that the module currently expects that a session will be removed from the database while a cookie is still valid, so I'll try to add another test for that case, since it's obviously possible (and likely), from the default inactive session timeout.
----
I'm a little baffled by the different behaviour between
/and/home/...A caching issue could be possible, or maybe something with the rendering context?
Comment #7
gappleI've opened #3349484: PL token won't start new session if old session expired from DB as a bug - let me know if the MR changes make an improvement for you
Comment #8
agileadamI'm happy to report: gapple's work in #3349484: PL token won't start new session if old session expired from DB fixed this issue! I look forward to being able to see this on a tagged release.
Thank you, gapple!
PS:
/and/homeare both working. I'm not sure what was going on. I have rebooted my machine, which recycled all of my ddev instances. Perhaps there was something funky going on with xdebug. Who knows!\Drupal\persistent_login\EventSubscriber\TokenHandler::loadTokenOnRequestEventis being called on every page load. Phew!Comment #9
gappleThat's great to hear.
Tagged release should be available shortly.