Logins not peristing anymore after upgrade to beta5

I'm configured for unlimited persist time.

Just to make sure about the process to reproduce your problem. Here's a few steps to try:

1) Go to Site Configuration -> Persistent Login and make sure the welcome message is enabled.
2) Logout.
3) Login with "Remember me" option checked.
4) Close all browser windows.
5) Open a browser window and visit the site again.

Now, you should be logged in and you should see the welcome back message. Is this what isn't working?

If so, this is hard to debug, so please, let me post a few questions that I hope can help focus on possible causes.

- Have you upgraded from beta4?
- Do you have page caching enabled?
- Are you on a multisite environment?
- Are you using login toboggan, ldap, phpcas or any similar module that alters the user login process?
- Could you please try with different browsers?

In case the above doesn't help. Could you please provide me with a plain account to the site, so I can test the login process and see what happens with the cookies? If so, then don't post it here, but use my contact form instead. :)

I've managed to reproduce the issue on 2 of my sites. One is www.<domain> and other is new.<domain>; for the first one cookies are <domain> only, while for the second one I have to use new.<domain> (specifying "$cookie_domain = 'new.<domain>'" in settings.php).

Here is what I've done:
1. Upgraded from 6.x-1.4-beta4 to 6.x-1.4-beta5 (using update.php and checking the "Persistent Login" settings after)

at this stage, everything was still functioning...

2. I've erased remembered sessions
3. I've logged out
4. I've successfully logged in again, enetring my username and password (selecting "remember me" option)
5. I've closed Firefox (3.0.9) browser
6. I've opened Firefox again
7. I've visited my site - as anonymous user only... :-(

It was like that (I've tried many times - the number of remembered sessions was increasing, but I was still not recognized on next visit...) until I've manually erased all cookies for my site in my Firefox (what was very easy using the "CookieSafe extension). After that, I've had to login again (with my credentials) and since then everything seems to work fine (I've cleared all my remembered sessions left from previous trials first, so there is only one now...)

So, I guess the issue is due to the fact that somehow the PERSISTENT_LOGIN_ cookie saved in Firefox is not updated (if there is already one present) according to the data saved on server side, when the user is logging in with "remember me" option selected (but has already some cookie from this site saved in browser for this purpose).

After my post #3, I've played a bit more. New cookies (generated since 6.x-1.4-beta5 is installed) seems to be OK. I've created a few remembered sessions from my PC, and everything was still working. I've cleared them all, and created a new one (without messing with cookies saved in Firefox) - no problem this time!

So, it seems that problematic are only older cookies, left from previous versions of "Persistent Login" in Firefox, which seems to be kept (instead of being properly replaced with a new one). What I was not careful about is that I've erased all 3 cookies at once in my test #3, so I con not say 100% that it is exactly PERSISTENT_LOGIN_ coookie the one to be blamed for the issue...

Quite annoying issue though, considering we can not ask all users of our sites to manually clean just exactly the right cookie from their browser (probably it would be very unpleasant if they would by mistake clean also some other cookies, needed for other sites...). So I can only hope that we will find a solution before they will clean their remembered sessions (everything should work well after the upgrade, as long as they will not touch their settings...).

And, this might be the issue also before, I am not sure that it is introduced exactly with the latest upgrade (altough I remember I've erased remembered sessions many times in the past, without such issues...)

Wow! Thanks for the detailed information. And sorry for these headaches, but I wanted to resolve the issue of being able to share the PL cookies under the same scope as the session cookies.

I may try to find a workaround, to see if the old cookie can be removed using setcookie().

Could you please try the following?

This is a change to persistent_login.module as shipped in Beta 5. The lines with the + need to be added to the code in that particular place, removing the leading +.

Well, the method described in my previous post seems to work here. I was able to reproduce the double cookie situation, and the fix worked leaving just the new cookie on the browser.

I committed an slight variation to CVS as I already made some changes since beta5. Here's the patch. And I'll release a new beta asap.

Thanks again for reporting and the detailed information provided. I hope the transition to the new cookie will be transparent to all users in next release.

Obviously this is not an issue...

I am not recignized again. I've patched the file, and the cookie was removed and newly generated, as expected. But, the new cookie somehow doesn't seems to match the record saved on server...

Here are details from my cookie:
Domain: .new.<mydomain>
Path: /
Name: PERSISTENT_LOGIN__
Value: 1%3A62270d33869ec476989b1a9cc1898292%3A7d696fee31e9bb022bfd42fc49673478
Secure: No
Expiration: 1272385311

And, here is what is saved in "persistent_login" table:
series: 62270d33869ec476989b1a9cc1898292
token: 7d696fee31e9bb022bfd42fc49673478
expires: 1272385307

I hope it helps...

After clearing remembered sessions, logging out, logging back in (with "remember me"), closing only the browser tab (but not closing Firefox itself), visiting the site again, I was recognized. Could it be that it is a problem if browser is closed immediately after the persistent login cookie is set, but before being used to recognize the next visit?

Now, the cookie data is:
Domain: .new.
Path: /
Name: PERSISTENT_LOGIN__
Value: 1%3A6890fb66ef6029c3a86234e3f4c2feff%3A760d67d0d35d24d603f4f2694f62c4a6
Secure: No
Expiration: 1272386199

And, the record in table:
series: 6890fb66ef6029c3a86234e3f4c2feff
token: 760d67d0d35d24d603f4f2694f62c4a6
expires: 1272386195

Everything seems to be the same as above, but this time it works... Weird!

Ooooops, after closing Firefox and opening it again, I am not recognized again...

I committed to CVS an slight variation of the quick fix I posted in #6. The fix in CVS checks to see if you have 2 cookies, and only removes the old one if so.

If you're running Beta5, the quick fix would be as follows:

Seems to be that Firefox is a bit more involved as I've thought.

As long as I am logged in, and I close Firefox ("Save and Quit"), next time I reopen it, everything is restored properly (I am recognized on my site). As soon as I close the tab first, and then Firefox, I am not recognized again.

But, this was not an issue with previous version at all!

markus_petrux,

thank you for quick responses, but we are obviously in a totally wrong way.

After playing a while (with unpatched beta5 and both your patches applied), I can not get my site new.<mydomain> to remember me after I close my Firefox without being logged into it (no matter with which version I try, original beta5 or the one with some patch applied...). As long as I am logged and close Firefox with "Save and quit", there is no problem.

At the same time, I can visit my other site <mydomain> as a registered user (properly recognized and logged in automatically) no matter what I do, if I am logged in when closing Firefox or close that window before...

Maybe the problem is that is certain situations, if there's more than one cookie with the same name, but different cookie domains, the value stored in the $_COOKIE is unknown. It could any of both values depending on something I don't know.

So maybe the only way to solve this would be using a completely different name for the PL cookie. I'm pretty sure this approach will solve the situation you described, LUTi. Let me code the fix and release beta6, so it can be quickly deployed and tested.

FYI: beta6 should be available pretty soon. I have changed the PL cookie name to avoid the mentioned conflicts. Hopefully this will fix the issue originally reported by aharown07.

I'm optimistic and set the issue as fixed. Please, re-open if it isn't. And again, apologies for the inconveniences. :(

Thanks. Just catching up. Will watch for beta6 and test as soon as its avail for download. In response to your questions, my situation appears to match LUTi's.

Have beta6 in now. Can confirm that logins are persisting properly now.

Sweet. Thanks for confirming.

I can now focus on the other issues and see if we can clean the queue so we can pack an official non-beta release for D6. :)

markus_petrux,

thank you for quick fixes, you are great.

The new version works fine only if PHP is 5.2 (or higher).

For lower versions (I believe quite common today around, considering for example in most recent RHEL 5.3 it is 5.1.6 only), only the error:
warning: setcookie() expects at most 6 parameters, 7 given in .../persistent_login.module on line 405.
is displayed (and cookie is not set).

The reason is that the 7th parameter was introduced with PHP version 5.2. It doesn't hurt to skip it (it is FALSE at the moment anyway), as I've seen you've done in -dev version already. I am providing a fix (in attachment) which is checking the PHP version and sets the cookie accordingly. Maybe this would be a more universal solution for possible further needs...

In any case, beta6 as it is now is not working for setups with PHP < 5.2, so I suggest you to publish an "official" updated version ASAP.

I am also noticing that beta6 sets a new cookie, but the old one remains in browser (I've had to manually delete it for both my sites...). Maybe it would be good that it is cleaned in the moment when the new one is set.

By the way, if you check your module with "Coder", there is 1 minor warning (cosmetic issue) and some smaller things to be done with installer. Nothing urgent, I believe, but it is always nice to see that Coder is not complaining at all, when a module is installed or updated, by my opinion. And, as a final touch, check the permissions of packed files - when I unpack recent versions, I get some files with x bits set (probably caused by a samba setup) on my linux server. It is not crucial (works well), but also not very nice (I am correcting it manually all the time).

Yep, the setcookie issue with PHP < 5.2 was reported/fixed here: #449350: warning: setcookie() expects at most 6 parameters, 7 given ...

As per the remaining cookie... ugh, I would prefer not adding code that's only required for the time these cookies remain on user browsers. Please, note that these cookies will simply expire in a few days. It shouldn't cause harm until then, I think.

As per the Coder issues... I just fixed a typo in a SQL statement I introduced here: #442782: Limit the number of PL records in the database per user. Oops! ...but that's not included in any beta, only in dev currently. Aside, the only notices I see in Coder are related to substr(), but do not apply there because we're checking stuff that's not encoded, AFAICT. Could you please open a separate issue if you still see Coder notices. In that case, please provide the Coder options and version to try to reproduce this on my system. I would be more than glad to fix any remaining issue. :)

Edit: I just committed @file comments to a couple of module scripts.

Thanks again for your help in squashing this bug! :)

Automatically closed -- issue fixed for 2 weeks with no activity.