When first visiting the site using a URL including a trailing slash (e.g. /admin/), Persistent Login fails, giving the Access Denied page. Initially visiting the same path without the trailing slash allows the persistent login to complete successfully.

In the persistent login history it shows that the token was used.
The browser retains the initial persistent login cookie.
No new token in the series is created; the persistent_login table no longer contains an entry for the series.

Comments

gapple’s picture

I suspect that the issue may occur due to Global Redirect calling drupal_goto during hook_init, and the new token not being correctly sent to the browser.

I don't remember testing if the same failure occurred when accessing a non-alias path (with configuration to redirect to the aliased path)

gapple’s picture

Just tested a basic configuration, using de-slash on a basic node url. I think the process flow is as follows:

1. persistent_login_boot() checks if the user has a PL token, and if successful invalidates the old token and calls user_external_login().

2. hook_init is called, hitting global_redirect_init() first. Global redirect detects the ending slash, and calls drupal_goto() with the deslashed address. An updated token is seemingly not generated (and consequently not stored or sent to the user in a new cookie value).

3. the user loads the deslashed page, but (a) PL login has set the session to not check for a valid PL again in hook_boot() and (b) the user's cookie sent with the request matches the old (now invalid token)

I think getting #943280: Deleting expired persistent login cookie for Boost compatibility tested and committed may make this somewhat easier to resolve

gapple’s picture

Version: 6.x-1.4 » 7.x-1.x-dev

Bumping version; fix in 7.x first and then backport to 6.x if possible.