#1544 Maintaining Session in Clustered Environment

[Anonymous]

Hi - I'm attempting to run MRBS in an IIS Cluster. I use AD based authentication and I'm finding it difficult to maintain session state as there's no guarantee which node in the cluster will be serving you MRBS on your next visit.

Is there any way of ensuring this in MRBS? Database sessions perhaps?

Thank you,
Sourjya

[Campbell Morrison]

Yes, database sessions are probably the answer. I'll take a look over the next couple of days.

[Anonymous]

Just as I thought. Thank you very much for looking into this.

Regards,
Sourjya

[John Beranek]

2 possibilities as it stands I think:

1. Session persistence configuration in your load balancer
2. 'cookie' session scheme

[John Beranek]

For 2. I need to remind myself what we did about CSRF protection - it may be you need to ensure PHP session support is disabled for MRBS.

[John Beranek]

So, hmm:

  // Sessions are only essential if we're using the 'php' session scheme.   For other schemes
  // they are desirable as if they are working we will use them for storing CSRF tokens, but
  // if they are not working we will fall back to other techniques, eg cookies.
  if ((false === session_start()) && ($auth['session'] == 'php'))

So, you need to disable PHP session support, or we could add a config variable to mean "Don't even ATTEMPT to use PHP sesssions" and then test that in this code.

[John Beranek]

No, scratch that I just forgot what && means ;) - I'll go back to sleep...

[John Beranek]

Aha, no - I did remember correctly...this code is the bit I meant:

// If sessions didn't work, then set a cookie containing the CSRF token.
if (session_id() === '')

[Campbell Morrison]

In the short term commenting out this line (42) in init.inc:

session_init();

should do the trick shouldn't it? If $auth['session'] is set to 'cookie' then session_id() will return '' and cookies will be used for CSRF tokens.

I think I'll go ahead and implement storing of session data in the database anyway. As well as being useful for the clustered environment, it will avoid the frequent problems we see where PHP sessions aren't working because the session tmp directory isn't writable.

[John Beranek]

Campbell: Both sound reasonable. A new "db" session scheme would need to handle session expiry/garbage collection (as PHP calls it).

[John Beranek]

You can get PHP's session support to save to a DB, but it seems a lot of effort for little gain in MBRS...

https://www.culttt.com/2013/02/04/how-to-save-php-sessions-to-a-database/

[Campbell Morrison]

It doesn't seem too much effort, or so I thought when I looked at it earlier! There are lots of standard implementaqtions out there which all look pretty much the same.

I was thinking of making it the standard way MRBS does 'php' sessions, rather than creating a new 'db' scheme. That way we avoid the not infrequent support issues of sessions not working because of some problem with session configuration.

[John Beranek]

Mmm, reading the very post I linked to fully does show it's pretty simple. I wonder if you'd keep the CSRF code attempting to use sessions, and therefore put the session DB class into common code, and not in session_php.inc.

[Campbell Morrison]

Yes, I was just thinking of creating a session DB class in lib/MRBS and then calling session_set_save_handler() in init.inc. Everything should be then be transparent to existing code that uses sessions.

[Campbell Morrison]

I've implemented database sessions in a named branch called 'db_sessions' and you can download the latest snapshot here. I'd welcome any feedback on it from any testing that you can do. Please note that

1. It involves a database upgrade, obviously, as it creates a new table to hold the db sessions.
2. It doesn't yet support $auth["session_php"]["session_expire_time"]. I'll take a look at that tomorrow hopefully.

[Campbell Morrison]

Oh, and also

(3) The minimum PHP version now required is 5.4.0

[John Beranek]

Campbell: Tricky issue with the branch...having updated the code to the branch I seem to have broken sessions before I can manage to do the DB upgrade:

The database needs to be upgraded. Please backup your database before proceeding.

Your session has expired.

[Campbell Morrison]

Mmm. I can't seem to reproduce this. Have you deliberately nobbled ordinary PHP sessions on your machine or something?

[Campbell Morrison]

The code now supports $auth["session_php"]["session_expire_time"].

[Campbell Morrison]

We have now completed testing and merged the branch with the default branch. You can download the latest code here. It will also appear in the next release of MRBS when it comes. Note that database sessions are now the default if you have $auth['session'] set to 'php' (also the default setting), so you don't need to do anything special to enable them.

Let us know of any problems.

[miCRoSCoPiC^eaRthLinG]

Campbell / John - thank you very much. This seems to work like a charm.

Regards,
Sourjya

[Campbell Morrison]

I should point out that I've just found a bug in the db session code. There was an error in the garbage collection code which will mean that your session table will just keep on growing and growing. Fixed in 99d5ec.

[miCRoSCoPiC^eaRthLinG]

Hi Campbell,
Thank you very much for fixing this.

Regards,
Sourjya