The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.We are using the http://drupal.org/project/securepages module. It is set up so that the user is pushed to https to log in.
When used with persistent_login, this results in the user not being re-logged in on http pages (e.g. the home page). When they then visit a https page (e.g. admin area) they are re-logged in.
This is caused by issues in _persistent_login_setcookie() and _persistent_login_get_cookie_name().
In _persistent_login_setcookie(), the setcookie() function is passes the session cookie parameter ($params['secure']) for the $secure parameter. Since we are logging in from https, this is set to true. As a result the persistent login cookie is never sent on http pages.
In _persistent_login_get_cookie_name() substring is used to remove the 'SESS' prefix from the session name. On secure pages this is set to 'SSESS' and so the name returned has an extra 'S' after the prefix.
I've attached a patch that makes these changes. _persistent_login_get_cookie_name() now used a regex ('/^SS?ESS/') to remove the prefix and setcookie is always called with 0 for the $secure parameter. This fixes the issue on my site, though I'm not sure if doing so introduces any security issues.
Another possibility would be to check the global $is_https variable and determine the session_name based on that.
| Comment | File | Size | Author |
|---|---|---|---|
| persistent_login-mixedmode_support-XXX-0.patch | 1.11 KB | Shaney |
Comments
Comment #1
djbobbydrake commentedSeeing a similar issue, using Persistent Login 6.x-1.4 and Secure Pages 6.x-2.x-dev. The issue we're seeing is that users are being logged out when they return to the site and attempt to visit a non-secure page using the secure url. The patch above doesn't work for us. Seeing if anyone has other thoughts on what the issue could be. User is not logged in (after being logged out) on a secure page that is supposed to be secure.
Comment #2
ptmkenny commentedThe patch worked for me, although I had to apply it manually. I am using Varnish and Redis on Pantheon with SSL enabled; SSL is enabled for the entire site via .htaccess rewriting. Persistent login didn't work out of the box, but it works now thanks to this patch! Many thanks @shaney!
Comment #3
ptmkenny commentedComment #4
asgorobets commentedThe patch works for us as well, we use Securepages in mixed mode and our /user page is protected, while homepage is HTTP only.
Comment #5
Anonymous (not verified) commentedIn my case Persistent Login with Secure Pages(on Login form) breaks the ability to logout and change user account, because when i go into the login form this module automatically log me as previous user.
This patch fix this and other problems for me, well done.
But.. can this patch open a security hole?
..a review by the maintainers would be appreciated.
Comment #6
gappleI definitely don't want to remove the secure cookie flag for all users, just to support Secure Pages, as is done in this patch.
I don't believe this would open any issues greater than having session cookies already transported over non-TLS.
(I'm also generally a strong advocate for full-TLS over only securing user pages, though I don't want to restrict others if they are not able to implement full-TLS for some reason.)
Comment #7
gappleI think at a minimum these changes need to be scoped to only apply when the Secure Page module is also enabled, in order to not remove the secure flag from the cookie for HTTPS-only sites.
Comment #8
aaronbaumanI'm not using Secure Pages, and I'm hitting this issue (D8)oops, sorry.
i'm not having this issue.
Comment #9
gappleWith the growing adoption of HTTPS, services like Let's Encrypt that make it available to everyone for free (and many hosting providers now integrating with their service), the increased emphasis from browsers for all websites to use HTTPS, and the risks of using mixed-mode HTTP / HTTPS, I don't think Persistent Login should support this configuration.