Forum cookie based persistent login issue [#1212774]

I've got the whole module up and running perfectly, its a great module once its all configured right, the only thing I can't seem to get working is the persistent login via phpbb cookies.

I can replicate the problem every time on my development machine and on a live server, i'm not sure if it is a config issue or something else.

This happens if Drupal or phpBB are master login, users can login, browse the forum all absolutely fine. Which suggests to me its not a problem with cookies in general.

When the phpbb forum session expires (which is the default 1 hour). As soon as this expires, if the user closes the browser then revisits the site, it doesn't matter which page, the site will redirect to the homepage (/node) and log out from both Drupal and phpBB. There is a bit of delay in all this that doesn't normally happen, as if it is trying to do *something*, then bombs out.

I can replicate it simply by logging in, then clearing the phpBB sessions table and refreshing the page. If I visit the forum url directly (i.e /phpbb3) after clearing this table, it picks up the cookie and redirects to the sid={session id} url correctly and logs in on its own, as it should. If I visit any Drupal URL it doesn't.

- This happens with all caching turned off
- The hidden login block is enabled.
- Cookie settings are right
- All extra validation options in phpBB are off

I am using Windows for both boxes, development in WAMP and live on IIS7. The one thing I did have some problems with was the path to phpBB. It is currently set to ./phpbb3 in the Drupal config for this module.

Any advice greatly appreciated.

Comments

Comment #1

Paul Lomax commented 13 July 2011 at 08:25

After a bit more digging it seems the demo site suffers from this problem too, as far as I can tell this module overrides both Drupals persistent login cookie and phpbb's, to the point of which they are more or less ignored. i.e if you log in and tick the 'keep me logged in' box. Then wait 24 hours and try and log in again you will be logged off.

This means the maximum length of time a user can stay logged in is dictated by the length of the phpbb session (the module advises 24 hours). Keeping sessions open for more than a few hours increases security issues and the risk of 'session jacking'.

I realise this is still a work in progress module, but is an improved cookie system on the radar for future releases?

Comment #2

snlnz commented 1 August 2011 at 10:52

Issue tags:

+phpbbforum cookie/session problem

Edited version:

Some notes I got from VB when we were experiencing cookie related issues were:

1) Download the latest dev version in our case was 6.x-2.0-dev: (*) No
2) Check email domain for valid MX record: (*) No
3) Force server URL settings: (*) Yes

4) Disable from phpbbforum module:
i) phpBB user ban checking: (*) No
ii) timezones synchronisation
iii) Save phpBBforum settings

5) Clear phpBB3 cache delete all files in /home/drupal-root/phpBB3/cache/*

6) Truncate phpBB3 sessions tables in the phpBB3 database
TRUNCATE TABLE `phpbb_sessions`
TRUNCATE TABLE `phpbb_sessions_keys`

7) Set cookie domain to:
.yourdomain.com

Side note:
Our phpbb session limit was working on 99999 but we have since set it to 86400 according to VB's best practice.

Test it out and let me know if this helps your forum?
I have been to hell and back with this issue and know my way round it quite quickly now so hopefully I can be of some assistance.

Comment #3

Paul Lomax commented 1 August 2011 at 11:05

Hi snlnz, thanks for that, the issue isn't session cookies, they work fine.

i.e If you log in, you will remain logged in for the duration of the session which is set to 86400 seconds (24 hours). This holds true of the demo site too on: http://phpbb.drupalbridge.org/en/forum.

If you log in, tick the 'Keep me logged in' checkbox, wait the 24 hours then try and visit the site again, you will be logged out. You can speed this process up by logging in, then truncating the phpbb_sessions table and reloading any page. You will get logged out immediately. The default behaviour for Drupal logins is to set a login cookie that lasts 22 days, phpbb's is 1 year. These are separate from session cookies, which are designed to last a couple of hours.

There are two session tables in phpbb 'phpbb_sessions' and 'phpbb_sessions_keys', the sessions table is short term, this gets periodically cleared when the timer hits the 86400 second limit. The session_keys table is long term and matches a permanent login cookie set in the users browser. This is the thing that doesn't seem to take.

Unless something has changed in the -dev version. I'm using -rc4 at the moment.

Comment #4

vb commented 1 August 2011 at 19:55

Enter 1900800 for 22 days
No changes relating to that issue since rc4

Comment #5

Paul Lomax commented 2 August 2011 at 08:18

Hi VB, thanks for that, all I needed to know really was that I wasn't going insane and the system really wasn't designed to use it. Is it on the cards to add that as a feature or is it just outside the bounds of what is possible?

I've currently set it to 8 days (691200), i've also set the ini_set('session.cache_expire', 691200); and ini_set('session.gc_maxlifetime', 691200); in the sites settings.php to 8 days so they both expire at the same time.

The session table currently hovers around 75mb which is pretty high really, so I think 22 days and it may start to creak, especially for really busy forums.

Comment #6

fizk commented 9 January 2012 at 06:50

Status:

Active

» Closed (works as designed)

Comment #7

Paul Lomax commented 9 January 2012 at 11:15

Version:	6.x-2.0-rc3	» 6.x-2.0-rc6
Status:	Closed (works as designed)	» Active

I'd say this is still a bug. This module effectively removes two pieces of important functionality from both phpbb and Drupal itself. Persistent cookies are effectively ignored from both systems. Instead using the session table and session cookie to remember users.

In order to keep users logged in for more than a few hours (so they don't need to enter their username and password every visit) you need to increase the length of sessions.

Sessions were never designed to be held open for more than a few hours, let alone several days so the current work around is incredibly insecure. Also to accommodate this, the session table on fairly busy sites can become massive, unstable and vastly increases the risk of corruption.