Have to log in again after browser close

I'm having the same troubles. This module doesn't work at all for me.
It can be tested here: http://www.after-hours-japan.com/
I've followed all the directions I can find, and I think I've got it set up properly, but it doesn't work.

Subscribing

Check the "persistent_login" table in your DB. Is a new row created when "remember me" is checked?

There could be another module causing a conflict. And old version of Login Destination was the culprit in my case.

HTH

I'm having a few similar issues, too. In testing & dev of the site, it worked just fine. Now the site's been rolled out to Real Live Users, they're wreaking their usual havoc, and the persistance is a bit flaky. There doesn't appear to be any pattern - sometimes it'll stay logged in for a couple of days at a time, othertimes it'll ask me to login every time the browser's closed.

I'm using LoginToboggan as well, if that makes a difference.
The persistent_login table in SQL appears to be happy - but I do appear to have multiple sessions for some users. At a quick glance, I notice 8 current sessions for a couple of users, and quite a few on 3 or 4... I'd be surprised if they were multi-multi-computer users.

Well, it doesn't appear to be Persistent Login (or Remember Me, which I also tried) at fault. Both have been uninstalled, and I'm still seeing the same problems.

If anybody can come up with any suggestions... http://drupal.org/node/1092186

@adrianc
Having multiple sessions for a user is not uncommon, especially if they use a public computer that clears cookies after each user, or have configured their browser to clear cookies on exit.

The only step I can think to help in debugging is to check your browser cookies when you first open your browser, and cross check those against the Drupal session table and the persistent login table in your database. You can also use a tool like firebug to check that the cookies are being properly sent in the request headers.

@graloth
Please check your browser cookies both before closing your browser and after restarting it. Check that the expiry times are correct, and that the cookies are actually retained after restarting your browser.

If you're using Varnish, check this

I changed the version from 6.x-1.4 to master because after testing out the latest 7.x-1.x-dev version, I'm having similar issues.

What's frustrating is that this module works perfectly on my test server, but not on my live site due to launch on 7/1. What's even more weird is that the Remember Me module works perfectly on both sites, but I want to use this one because I really like that welcome back user message.

I did make sure to change the value of session.cookie_lifetime to 0 on Persistent Login & back to 2000000 for Remember Me. I also have the LoginToboggan module enabled on both (but haven't configured it so far whatsoever). Anyone else having similar issues for D7?

I really need some more information in order to progress this issue.

both 6.x and 7.x dev have a feature to log token invalidations, but most importantly I need to know that the cookies are getting sent from the server with the correct values and expiry, and whether they are being retained by the browser after a restart.

@Jay Lee
What environments are you using on test & live? any proxies?

Gapple, thanks for your quick response. You're not gonna believe it, but after comparing every freakin' module on my live & test sites, I figured out what was causing this issue: http://drupal.org/project/front

I used the Front Page module to create a "Coming soon!" page for visitors to leave their email addresses while I built the site (and obviously I didn't need to do this on my test server). So when I configured it to have visitors redirected to the comingsoon.php page, it was this that made Persistent Login not work anymore (I believe everything is ok if I enable Front Page & leave the configuration to default settings).

You can see what I'm talking about at http://discography.by, which redirects you to http://discography.by/comingsoon.php. You can bypass it by going directly to http://discography.by/user, but I currently have the Remember Me module enabled. I'll use Persistent Login when the site launches to the public on 7/1 or whenever you fix it, whichever is earlier.

I also let the maintainer of Front Page know of this issue at http://drupal.org/node/1638014. Maybe you & timhilliard can collaborate to fix this error?

I wasn't using the front page module, but I was using Login Tobbogan - I wonder if this was the culprit in my case, as it also plays with the login process.

Jaypan, are you still having the issue? I'm also using LoginToboggan, just configured it to exactly how I want it, and so far it's not causing any issues whatsoever on either of my live & test sites as far as I can tell.

I personally am not having the problem anymore, but I'm not sure about my users. I'll ask to find out and get back to you in a day or two. Login toboggan was just a guess, as it was the only module I could think of that had anything to do with the login process.

The issue may not be the login process, but with conflicts in hook_init when the PL cookie is read and updated. Determining whether cookies are properly set and retained by the browser will tell which is the case.

#897868: Failure when Global Redirect de-slash enabled is most likely an issue due to conflicts between each module's hook_init, and resolving it may hopefully fix some of the issues here as well.

I also have sever issues with this module: on FireFox it doesn't log me out (remember me not set). On Opera it logs me out, and the remember me checkbox doesn't work.

And yes, entry is made in the persistent_login table with 30 days expiry.

OK, the FireFox behavior is apparently "by design":

Firefox has a feature where you close Firefox and it offers to save all your tabs, and then you restore the browser and those tabs come back. That's called session restore. What I didn't realize is that it'll also restore all the session cookies for those pages too! It treats it like you had never closed the browser.

To get FF to behave: first close the tab, then the browser and it will indeed forget the cookie.

The problem with Opera was that I had set it to remove new cookies upon exit. Once that was fixed, I couldn't repeat the problem anymore with Opera. Logintoboggan was enabled too.

FireFox was a bit harder. I think I ended up with removing the domain cookies, and trying again and perhaps again. At some point it started working, without having to enable/disable any modules or making any database changes.

Given that I did some extensive testing I think the functionality works, so marking as closed.

thank you for providing updates and the resolution to your issues, @berenddeboer.

other user's problems have not been linked to browser configuration, so I am setting the issue back to its original status.

This occured to me when I had set session to expire after 0 days (unlimited). The cookie I got was valid until somewhere in 2038, but on browser close I had to revalidate. After setting tie value to 1000 days the problem was gone. (I just did this so I don't know if it will actually last 1000 days) Perhaps there is some check that does not treat 0 as unlimited but as 0 instead?

Update
Half an hour later I had to login again.

I currently have the Remember Me module enabled. I'll use Persistent Login when the site launches to the public on 7/1 or whenever you fix it, whichever is earlier.

Crap, I was using the beta release. Switching to the dev release (what this ticket is about) solved the problem.

Neograph734, I did a quick test for this module on one of my sites that I was having issues with and #21 worked for me too. Thanks!

Don't get too excited. I am still having some issues, but it did improve for subsequent test. After a while is fails again. Log simply says the previous token has been used and no sign of any error.

What's weird for me is that now I also don't have what used to be a much bigger problem. I didn't do anything special:

I just switched to the dev version this morning and immediately noticed that the login problem after closing a browser was resolved. After a couple of hours, I also noticed that now I can access restricted areas (such as trying to edit my profile) where I know I couldn't access before. I'm very happy at the moment, but will report back if any of the problems happen again.

P.S. I didn't empty the cache, but it's worth noting that I had disabled the module a few days ago. Emptying it is highly recommended after upgrading.

It appears hook_boot was not always invoked when loading the frontpage, so the check was not performed (tested by adding an echo in persistent_login_boot()). Navigating to another page logged me in instantly.

So the issue for me is that there was some caching somewhere. I've cleared browser cache and APC without effect. Then I went to /admin/config/development/performance and disabled "Cache pages for anonymous users". That did the trick for me and hook_boot now works and I get welcome message every time after closing the browser.

APC and memcached can deliver the frontpage quite quickly, so I have no real drawbacks but it is strange that hook_boot is not called when this caching is enabled. I guess most of us would want to cache pages for anonymous users. Trying to find if this a known core issue...

It appears that after enabling the cache again this module works as expected. So there was still some old page cache blocking the hook from getting called somehow.

Perhaps this module should call cache_clear_all('*', 'cache_page', TRUE); in hook_enable() in order to work properly?

And that only worked until some anonymous person visited the front page as it got cached wrongly after that. So I suppose core does a bad job loading a page from cache before running hook_boot.

I've added the following two lines of code after line 339 to prevent Drupal from caching the page during the boot. It is after isset($_COOKIE[$cookie_name]) thus if there is no cookie (anonymous page request) the page will be cached and delivered. (No performance drawback for unknown persons.)

// These are the requests we don't want to cache.
drupal_page_is_cacheable(FALSE);

Make sure you hit Clear Cache after applying this to remove the faulty cached page(s).

NOTE:
In order for this to work, you also need to apply this core issue #322104: Allow hook_boot() to disable page cache

Unfortunately page caching for anonymous users comes with multiple problems. I created an ajax-based login form, but it doesn't work when page caching turned on, as it only works for the first user to visit the page. There is a thread open on it somewhere.

Yeah, it appear that my enthusiasm of yesterday was for nothing as today I got wrongly cached pages again. Perhaps this module should throw a message that caching pages for anonymous users should be disabled? The same as what happens with the PHP session cookies?

It will need some further testing, but reading through the code I'm not sure that page caching should be an issue.
Unless page_cache_invoke_hooks is set to false, hook_boot is called before the page is served from cache. If the persistent login token is valid, the user is then logged in and a drupal_goto is called to start a new request, and drupal_serve_page_from_cache() is never invoked.
The only instance where I can think this would fail is if the page is served from the browser cache (never giving PL a chance to act).

I am not sure where and how this goes wrong, but after disabling caching for anonymous users the problem did not come back. So it is definitely related to caching, I just could not figure out how and why.