By AdrianC-1 on

Now that the long-in-gestation site has finally gone live, I'm starting to get a lot of failures in retaining logins - not just me, users are complaining.

I started off with Persistent Login. Cookies were present, and tied in with the database entries.
I've deactivated that, and tried Remember Me.

Both seem to behave very similarly - they retain the login if you visit very frequently (as in about hourly), but not if you leave it longer (as short as a few hours). Both have been set to roughly a month (4wks for RM, 30 days for PL) timeout.

Help! What IS going on here? Is anybody else having problems?

The site uses quite a few modules - probably the most relevant are Login Toboggan and phpbbforum. Everything's latest-release. Cron runs daily in the wee small hours (and, yes, it's losing logins between cron runs)

Any thoughts? Any alternatives to try?

⋅ Categories: Drupal 6.x

Comments

AdrianC-1’s picture

AdrianC-1 commented

was that PersistentLogin reduced settings.php's default session_cookie_lifetime to 0. RememberMe uses that - so I brought it back up.

And still had to log in this morning.

AdrianC-1’s picture

AdrianC-1 commented

Both Persistent Login and Remember Me are now disabled - and the problems are still occurring.

I'm starting to get quite frustrated by this - any suggestions gratefully received. Any rough directions in which to investigate also gratefully received.

mpavankumar’s picture

mpavankumar commented

subscribing

AdrianC-1’s picture

AdrianC-1 commented

Are you having similar problems?

mpavankumar’s picture

mpavankumar commented

i do observe the similar problem in a site i'm working, i am using remember me module. Now i want the login cookie should be stored for all users(with/without selecting the remember me option) for sufficient period of time say 4 weeks.

AdrianC-1’s picture

AdrianC-1 commented

I've installed a "clean" site on the same server, and been testing against that.

- It's not the web server itself. The clean site works fine.
- It's nothing in settings.php. Apart from using a different database and different cookie domain (there's multiple domain names (same name, different TLDs) pointing to the site), they're identical.
- It's nothing in the Drupal files. I've copied all of ../sites/all over, enabled all the modules & theme, and it works fine.

Next step is to import a backup of the production site's database, see if that brings the problem in.

If not, then I'll just switch over production to the working copy. If it does, then we can start tracking down within the db.

The one exception at the moment is phpbbforum - I've left that out of the clean. Again, try that separately, in case it's related to the session handling from that.

AlfTheCat’s picture

AlfTheCat commented

Since you welcomed rough directions, perhaps the session expire_module is worth a shot. I use it on a website for the opposite purpose, I want to log users out well before Drupal's standard period of 23 days.

I've never really encountered your issue so there's not a lot more I can think of to advise at this time. Except perhaps your cron frequency. For busy sites/ sites using a lot of modules, the cron tasks can pile up quite significantly. I personally set cron to run every 15 minutes but on a heavy site I even have it set to 2 minutes. Maybe, after cron has been waiting to run for a full day, something times out or the sessions table gets fudged which is updated on cron runs.
At least, it would be interesting to see if cron empties this table every time it runs. That would provide a clue to the underlying problem, and hopefully session_expire will provide some relief in the meantime. Chances are it will.

Hope this helps and I'm curious to learn your progress.

----
"People make mistakes. To really mess something up you need a computer."

AdrianC-1’s picture

AdrianC-1 commented

Reading the description of session_expire, I'm not sure it'll help - I've ruled out it being a server/Apache/PHP issue, since my "clean" test site on the same server's working just fine.

I've not set Cron up on that site yet - I'll do so now. Again, I'm not sure that that's going to be the issue, though - timeouts seem to happen after a (reasonably consistent, although I've not logged times - perhaps I should) couple of hours not visiting the site. Having said that, phpbbforum seems to timeout a little quicker - if I re-visit and am logged back in, sometimes I'll have to log in to phpbbforum separately.

Again, though, (and this is a bit trickier to be sure, since I've only set phpbbforum up on the clean site today), the clean site appears to be playing nicely.

My head hurts...

AdrianC-1’s picture

AdrianC-1 commented

I think we've got a big clue.

A lot of the site - including the vast majority of the users - was migrated from PostNuke, largely using the migration instructions here - http://drupal.org/node/237507

Users created in Drupal aren't seeing the logging-out problem.
Users created in PostNuke and migrated are.

The only difference I can see in the entries in the users table is the timezone column - the migrated users tend to be 0, the Drupal-created users tend to be 3600. Manually changing the contents doesn't seem to have made a difference. timezone_name is the same for both - "Europe/London".

But what else could be different?

AdrianC-1’s picture

AdrianC-1 commented

This is still driving me up the wall. I can't find anything that's different about the Postnuke-imported users and the newly created users.

Does anybody know what columns from which tables are involved in the session management?

gforce301’s picture

gforce301 commented

Session life time is typically controlled in settings.php. Specifically the 'session.cookie_lifetime' directive which in a default Drupal 6 installation is 2000000 sec (around 23 days). If that setting is still at that default, the you have some module which is killing your sessions early.

AdrianC-1’s picture

AdrianC-1 commented

Ah, but...

It's not behaving equally for all users.

Users migrated in from PostNuke are having the session killed after an hour or two.
Users created in Drupal are behaving properly.

dunx’s picture

dunx commented

I'm performing a similar task, but not as far advanced as you. I can see the timezone differences, but like you don't think that's relevant. The only other thing I did was to ensure all my created users were added to the authenticated users role.

Something like:
INSERT INTO drupal.users_roles (uid, rid) SELECT pn_uid, 2 FROM pn.nuke_group_membership WHERE pn_uid>2 AND pn_gid=1

The first "2" is the rid for "Authenticated user" from the Drupal role table and pn_gid=1 is my PN "Users" group.

They may be being logged off as Drupal is assuming they're anonymous in some way as they're not marked as authenticated.

I haven't tested this is a solution to your issue; it's just a suggestion.

AdrianC-1’s picture

AdrianC-1 commented

I've just checked a recently created user (member of a specific group) and a migrated user (member of the same group) - both only have rid=4 in the users_roles table.

Other newly created users don't have any entries in the users_roles table at all - and there's no entries at all for rid=2 in users_roles.

I've added rid=2 for a specific uid, and I'll keep an eye on it.

Looking at the user's profile and the list of group memberships for both a user without rid=2 and one with shows the same thing for "Authenticated user" - a greyed-out checkbox.

dunx’s picture

dunx commented

Have a look in the d.role table for the correct rid for Authenticated user. I'm not sure this is your issue though as I can't imagine there's any logic in drupal that's expiring logins for users not in rid 2. It might point you in the right direction though...

AdrianC-1’s picture

AdrianC-1 commented

Yep, it is rid=2

I left that test user logged in last night, and this morning needed to log 'em in again...

dunx’s picture

dunx commented

From http://drupal.org/node/237507

That's setting d.created to n.pn_user_regdate, d.access to a 2007 timestamp and d.login to 0. That 0 strikes me as odd as it implies they have no last login, but do have a last access.

I'm going to set d.login and d.access to the same value. I'm actually taking the date from the nuke_phpbb_users.user_lastvisit column, rather than setting to an arbitrary 2007 date, but you may not be using PNphpbb2 on your PN site.

Note if you do and you decide to go that route, that not all registered users will have accessed the forum, so values will be missing. I had to sweep each table and construct a PHP array to use for the insert, rather than use the simple INSERT... SELECT statement from the link above. In fact my migration script already stretches to over 2200 lines as much of my site's content is bespoke anyway.

AdrianC-1’s picture

AdrianC-1 commented

Dunx,

Thanks for that - but once the migrated user's logged in once, the access and login columns in d.users reflect (correctly) their last login to Drupal - the migrated values are only relevant before they visit Drupal at all.

I was using PNphpBB, yes - and am using phpbbforum on Drupal. It's crossed my mind that it may be related to that, rather than to core Drupal - but, again, migrated users misbehave, created ones play nicely.

But that's not necessarily an all-clear, is it? After all, the migration from PNphpBB2 to phpbbforum included migrating the user tables. Except the problem applies to users who don't have access to the forum at all, so won't have had any entry in phpbb's database. Hmmm...
dunx’s picture

dunx commented

I'll be using advanced_forum, which was supposed to be today's job, but I got side-tracked by geocoding. If I find anything when I get a bit further on, I'll be sure to post back.