I am getting a "Please verify your username and password to access this page." screen when trying to get any of the restricted pages (which is expected), but entering username/password does never get through.
Steps to reproduce:
1. close browser (to clear session and trigger PL login)
2. open browser, navigate to the site
3. observe "welcome back, user." message
4. navigate to user/%/edit
5. observe "Please verify your username and password to access this page." page
6. try to login
- expected to get to 'user/%/edit' page, but getting "Please verify your username and password to access this page." again and again.
I suspected it is a special case that was causing it (as new theme had it while the error did not happen with old theme), so I dug into it and found that if the page had an image served from a private file system, the error would be happening, and removing the link removed the error.
Digging further it looks like the logic of using $_SESSION (which is shared between all requests from same client) works ONLY if there are no parallel requests from the browser, as the request to the image file causes the PL to re-login the user, and $_SESSION PL variables are all messed up and forced login never gets through.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | persistent_login_restricted_pages-1955996-2.patch | 3.97 KB | iva2k |
Comments
Comment #1
iva2k commentedThere is an additional cosmetic problem - in this sequence:
1. close browser
2. open browser, navigate to the site.com/user/%/edit
Two contradicting messages are shown together:
- "Welcome back, user."
- "Please verify your username and password to access this page."
This problem does not depend on the theme or parallel requests from the browser.
I am filing it under the same issue as I already looked at the code and the fix of both problems will be done at once (patch is coming)
Comment #2
iva2k commentedHere's a patch that fixes both aspects of the problem by improving the business logic of PL.
The "welcome back" message is removed if "Please verify your username and password" is shown by moving the message code from hook_boot to hook_init and by setting the "welcomed" flag on the way to "Please verify your username and password" page.
The top issue is fixed by returning early from _persistent_login_check() if $_SESSION['persistent_login_reauth'] flag is set.
There is an additional fix for cases when user navigates to a non-restricted page without logging in after seeing the "Please verify your username and password" message. PL was loosing the logged in state, which is not consistent with standard practice.
I successfully tested the following sequences (with and without image file loaded from private file system):
Sequence A (typical)
1. close browser
2. open browser, navigate to the site
3. observe "welcome back, user." message
4. navigate to user/%/edit
5. observe "Please verify your username and password to access this page." page
6. login
(should see user/%/edit page)
Sequence B (typical + no login)
1. close browser
2. open browser, navigate to site.com/user/%/edit
3. observe "welcome back, user." message
4. navigate to user/%/edit
5. observe "Please verify your username and password to access this page." page
6. navigate to home page
(should see the user is still logged in)
Sequence C (browser session restore)
1. close browser
2. open browser, navigate to site.com/user/%/edit
3. observe no "welcome back, user." message but "Please verify your username and password to access this page." page
4. login
(should see user/%/edit page)
Sequence D (browser session restore + no login)
1. close browser
2. open browser, navigate to site.com/user/%/edit
3. observe no "welcome back, user." message but "Please verify your username and password to access this page." page
4. navigate to home page
(should see the user is still logged in)
Comment #3
iva2k commentedComment #3.0
iva2k commentedclarify
Comment #4
deanflory commentedI'm getting this when trying to go to the Persistent Login admin page:
/user/login?destination=admin/config/system/persistent_login
Each time I submit the login form, it logs me in and redirects me right back to the same page listed above. I am using the Better Login module but I don't see how that would affect the destination part not kicking-in after submission.
EDIT: My issue was fixed by disabling, uninstalling, running cron, flushing cache twice and then re-enabling the Persistent Login module.
Comment #5
jay.lee.bio commentedThanks for the patch. I was about to test it when this problem suddenly disappeared after I upgraded to the latest dev version: https://www.drupal.org/node/887608, #24
Maybe this patch has already been committed, which I haven't checked. I'll report back if this problem happens again.
Comment #6
jay.lee.bio commentedOk the problem has come back. The bad news is that both #2 & #4 didn't work for me. The real bad news is that sometimes I'm able to access restricted pages and sometimes not, meaning the issue just arises randomly that I can't seem to figure out a pattern at all. But the good news is that I was able to figure out a temporary solution:
I went to the settings page (admin/config/system/persistent_login) and left the "Pages" field empty. The following are what used to be there:
user/*/*
user/*/address
cart/checkout
admin/config/system/persistent_login
If anyone has a good reason (especially in terms of security) why I shouldn't do this until someone figures out a permanent solution, please let me know. Thanks!
Comment #7
neograph734I ran into the same issue. It did work when I deployed it, but as of now I keep ending up at the login page. Will give #2 and #4 a shot tomorrow.
Comment #8
neograph734Setting this to major priority as the module does not function as supposed.
Comment #9
gappleUpdated issue title
Comment #10
deanflory commentedI reported this happened to me 2 years ago in #4 and it's now happened to me again, so there is some circumstance where this module just fails outright.
This is the path giving me problems (haven't tested others):
/user/login?destination=admin/config/system/persistent_login
Comment #11
gappleClosing out 7.x issues