Session timeout errors after upgrading php to 5.4

[charlottezweb]

Hi, we upgraded a server today from PHP 5.2.x to 5.4.x and one forum on the server started getting the session timed out messages for basically every action.  It wasn't sporadic, we couldn't login at all.  For the admin who was already logged in, every action he tried resulted in that same error.  To our knowledge, basically nobody could post or do anything.

Curiously, another SMF forum (same version, 2.0.7) on the same server is working fine.  Go figure.

We tried the cookie name change without any luck.

I've read the threads about the session.hash_bits_per_character and the issues it can have with 6 but it's already set to 4 which I've read should avoid that problem.

Anything else that I'm missing?

phpinfo for that server

Should I give this thread a try even though the session.hash variable is already 4 and other SMF forums on the same PHP instance work?

http://www.simplemachines.org/community/index.php?topic=447598.msg3397756#msg3397756

Thanks,
Jason

[Illori]

might help but i am not sure it is the same cause

After a bit of research, I figured out what your problem is.

Your PHP configuration uses sha256 for creating session IDs. This will result in session IDs being 64 characters long. The problem is, SMF currently doesn't support session IDs longer than 32 characters (2.1 will support 64-character session IDs). This results in the session ID getting cut off in the database, so when SMF goes to check the one from PHP with what's in the database, they won't match.

There are two options for fixing this, depending on your preferences.

Option 1: Edit your php.ini file to have "session.hash_function = 0" instead of "session.hash_function = sha256". This will cause PHP to use md5 for session IDs, which will result in a standard 32-character session ID.

Option 2: Run these queries in phpMyAdmin to allow SMF to support longer session IDs.

Code Select Expand

ALTER TABLE smf_log_errors CHANGE session session char(64) NOT NULL;
ALTER TABLE smf_log_online CHANGE session session char(64) NOT NULL;
ALTER TABLE smf_sessions CHANGE session_id session_id char(64) NOT NULL;

Note that the 2nd option will only fix it for that specific install. If you plan on installing additional instances of SMF elsewhere on the server, you will have to run those queries each time you install SMF.

[charlottezweb]

I can try it but if that was the case, the other SMF forum on the server shouldn't be working fine but it is...

That's what's weird.

[charlottezweb]

might help but i am not sure it is the same cause

After a bit of research, I figured out what your problem is.

Your PHP configuration uses sha256 for creating session IDs. This will result in session IDs being 64 characters long. The problem is, SMF currently doesn't support session IDs longer than 32 characters (2.1 will support 64-character session IDs). This results in the session ID getting cut off in the database, so when SMF goes to check the one from PHP with what's in the database, they won't match.

There are two options for fixing this, depending on your preferences.

Option 1: Edit your php.ini file to have "session.hash_function = 0" instead of "session.hash_function = sha256". This will cause PHP to use md5 for session IDs, which will result in a standard 32-character session ID.

Option 2: Run these queries in phpMyAdmin to allow SMF to support longer session IDs.

Code Select Expand

ALTER TABLE smf_log_errors CHANGE session session char(64) NOT NULL;
ALTER TABLE smf_log_online CHANGE session session char(64) NOT NULL;
ALTER TABLE smf_sessions CHANGE session_id session_id char(64) NOT NULL;

Note that the 2nd option will only fix it for that specific install. If you plan on installing additional instances of SMF elsewhere on the server, you will have to run those queries each time you install SMF.

I was just re-reading this. 

The first suggestion (make session.hash_function = 0) wouldn't apply as that's what it is already.

Not sure if that would negate option 2 or not.

We're still looking into other possiblities.

Any other feedback is welcomed.  Thanks!

-Jason

[margarett]

Just to exclude the possibility of a wrong_sized session ID, can you please add

Code Select Expand


echo session_id();
exit;

in index.php, after

Code Select Expand

// Start the session. (assuming it hasn't already been.)
loadSession();

And check what's returned? I get something like this:

Code Select Expand

2clm86udt40j6u4uesfkucanf6
It has to be below 32 characters

[charlottezweb]

Just to exclude the possibility of a wrong_sized session ID, can you please add

Code Select Expand


echo session_id();
exit;

in index.php, after

Code Select Expand

// Start the session. (assuming it hasn't already been.)
loadSession();

And check what's returned? I get something like this:

Code Select Expand

2clm86udt40j6u4uesfkucanf6
It has to be below 32 characters

Thanks.  The one displayed was 26 characters (all lowercase, alpha-numeric, no symbols).

[margarett]

Then it is not related to that. Can you check the content of the table smf_sessions? Are the sessions the same?
Maybe you can try to truncate that table?

(Yes, I'm just throwing wild guesses...)