#2215 (ok 2.9.2) broken cluster session wrappers

[sopak]

problem:
due hardcoded settings, PHP sesion wrappers are broken
and remember data across cluster are imposible

./libraries/session.inc.php
line 98:

ini_set('session.save_handler', 'files');

solution:
let this to be decide on php configuration or does not
make it default,
please remove this piece of code thanks

version 2.8.1 is also afected

[sopak]

Logged In: YES
user_id=1572935

original update:

// [2006-01-25] Nicola Asuni - www.tecnick.com: maybe the
PHP directive
// session.save_handler is set to another value like "user"
ini_set('session.save_handler', 'files');

[Christian Schmidt]

Logged In: YES
user_id=32013

I suggest adding a setting in confic.inc.php that allows
specifying a custom session handler.

Perhaps phpMyAdmin could supply a database driven session
handler that writes to the database specified in
$cfg['Servers'][$i]['pmadb']. This would be useful for
people running webservers in a cluster that don't have their
own custom session handler (because they don't use sessions
outside phpMyAdmin).

[Jürgen Wind]

Logged In: YES
user_id=1383652
Originator: NO

>Perhaps phpMyAdmin could supply a database driven session...
I second that (if it's assured that no one else has access to my session of course).

[Marc Delisle]

Logged In: YES
user_id=210714
Originator: NO

A new setting for this will be difficult to implement, because session.inc.php is executed before config parameters are parsed (since the session is used to store them).

[Jürgen Wind]

Logged In: YES
user_id=1383652
Originator: NO

// [2006-01-25] Nicola Asuni - www.tecnick.com: maybe the PHP directive
// session.save_handler is set to another value like "user"
ini_set('session.save_handler', 'files');

i did'nt find a clue in trk or in mailing lists,
what was the reason to override the php.ini settings?

[Marc Delisle]

Logged In: YES
user_id=210714
Originator: NO

Juergen,
here is the reason:
https://sourceforge.net/tracker/index.php?func=detail&aid=1414628&group_id=23067&atid=377408

I agree that we must support clusters / load balancers but I don't see how. Maybe we would need an additional small config file that is read by session.inc.php and indicates which session handler to use. Possibly there could be credentials to establish the connection to a db-based session handler but I don't like the security implications of having these in a config file.

Or we could just add a FAQ entry, explaining to remove this line from session.inc.php in case of load balancers :)

[Jürgen Wind]

Logged In: YES
user_id=1383652
Originator: NO

Marc,
default setting in php.ini : [Session] ; Handler used to store/retrieve data.
session.save_handler = files

if someone deliberately changes this value obviously he doesn't want to use "files".
this implements he will take care of it by autoprepending all .php scripts with his own handler.

so there is no need for ini_set("session.save_handler", "files"); in pma.
even more: it prevents pma from making use of the user's handler.

if the user wants to integrate his own handler in pma directly, he easily can add a line

if(ini_get('session.save_handler') != 'files') require_once('myOwnSessionHandler.inc.php');
or somesuch anywhere before session_start(); (maybe pma even can provide a pmadb based handler here in a later version depending on a $cfg['SessionHandler'] = './pmaSessionHandler.inc.php';)

i think sopak is completly right.
YMMV

[Marc Delisle]

Logged In: YES
user_id=210714
Originator: NO

Juergen,
ok it makes sense but I am not sure if we would be covering all cases (for example a host provider that has changed session.save_handler for a virtual host and does not provide a handler). I just asked Nicola Asuni to come here and comment further, to get more input about this.

[sopak]

Logged In: YES
user_id=1572935
Originator: YES

I am not seeing any reason, why not leave decision on server administrator.
Thats same issue as some applications trying set session.save_path to default /tmp/sess, which is again insane(we have separate temporary files for all our accounts, we are mass webhosting company with balanced and failovered servers).

Lem9: If server admin do not provide correct setup for handler, then they have to work it together. Code of phpmyadmin is not place to solve server missconfiguration.

anyway: thanks for your effort in this and enjoy new year

[Marc Delisle]

Logged In: YES
user_id=210714
Originator: NO

The ini_set has been removed in 2.9.2.

[Nicola Asuni]

Logged In: YES
user_id=1191518
Originator: NO

The following seems to be a PHP error (please verify):

if you manually set (just for testing):
ini_set('session.save_handler', 'user');

and then execute:
session_start();

the session crashes without rising any error or exception, even using
error_reporting(E_ALL | E_STRICT);

So, seems that there is no way to catch this kind of error.
Probably the session_start try to find a custom user handler that do not exist and crashes.

I agree with windkiel, the default php.ini setting is
session.save_handler = files
so, the only thing we can do is to add a FAQ entry for this problem and open a new bug on PHP site if someone could confirm my experience.

[Jürgen Wind]

Logged In: YES
user_id=1383652
Originator: NO

@Nicola,
i can't confirm your findings;
this short test on php 5.2.0 (win32):

<?php
ini\_set\('display\_errors','On'\);
error\_reporting\(E\_ALL\);
ini\_set\('session.save\_handler', 'user'\); \# test
session\_start\(\);

throws:
Fatal error: session_start() [<a href='function.session-start'>function.session-start</a>]: Failed to initialize storage module: user (path: ) in D:\HTdocs\2007\start.php on line 5

[Nicola Asuni]

Logged In: YES
user_id=1191518
Originator: NO

Yes you are right, it's not a php bug.
Unfortunately PHP do not allows to direct catch Fatal Errors, unless you implement the following strategy:
http://www.zend.com/zend/spotlight/code-gallery-wade9.php?article=code-gallery-wade9&kind=sl&id=11805&open=1&anc=0&view=1