News:

Wondering if this will always be free?  See why free is better.

Main Menu

2.0.14 session_start(): Failed to decode....

Started by NekoSensei, May 31, 2017, 05:07:37 PM

Previous topic - Next topic

NekoSensei

Is it possible that these errors come from the fact that some spam robots block cookies?

shawnb61

My initial thought is no.  My understanding is that when cookies are blocked php resorts to putting the session ID in the URL instead.  I don't think that would affect session contents. 

It is more likely that there is something unusual about sessions for bots under some circumstances. 

Could you find the lengths of your longest & shortest sessions?  You should be able to run these queries in the SQL window in phpMyAdmin:
SELECT LENGTH(data) AS maxlen FROM smf_sessions ORDER BY maxlen DESC LIMIT 1;
SELECT LENGTH(data) AS minlen FROM smf_sessions ORDER BY minlen ASC LIMIT 1;


Maybe something will stand out...  (My sessions range from ~80 bytes to ~4K bytes)
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

NekoSensei

For the moment with your 2 requests I get this:

maxlen
3622

minlen
82

shawnb61

Thanks for sending me your session info.  It all looks good.  (I.e., the bad ones are getting destroyed just as the message says.)

Let me ponder this...  I may have something for you to test in a bit... 
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

shawnb61

NekoSensei -
Are you still having this issue?   If so, I'll get you some code to test.
Sorry for leaving you hanging, a few things came up.
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

NekoSensei

hi shawnb61, yes it's always the same and I just cleaned fifty error messages from the same robot ... lol

shawnb61

I have been working with NekoSensei offline on this.  What we have learned:
- This activity was traced to a known malicious spammer
- The session problems were caused by special UTF8 characters in the search field
- The problems went away when NekoSensei rewrote the ban messages in English (all ISO-8859-1, no UTF8)

The true underlying problem is that searches for strings with multi-byte UTF8 characters cause session issues.  It appears the spammer was searching the site for his/her ban message (which is why the issues went away when NekoSensei changed the ban messages).   

However, you can still reproduce all the symptoms by searching for multi-byte strings.  A bug has been logged for this.   

Note that the search works fine; the message is logged in the background & the session is rebuilt in the background.  There is no user impact, just worrisome entries in the error log. 

Thanks to NekoSensei for being patient & providing all sorts of helpful info. 
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Arantor

If the session table isn't UTF-8, all manner of stupid stuff could happen now sessions are done with JSON.

shawnb61

This even occurs if everything is UTF8.  And it's not the JSON encoding, not directly, anyway.  It has to do with the internal session_encode() not liking UTF8.  This error is on 2.0 & 2.1.  For more info, check out issue #4444 on Github.
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

albertlast

Like i mention in #4444 the information are not enough to reproduce the error.
Would be nice to get a more detail guid to see the issue.

Arantor

Try changing the @ini_set('session.serialize_handler', 'php'); to @ini_set('session.serialize_handler', 'php_serialize');

Requires PHP 5.5.4

Colin

Quote from: shawnb61 on December 30, 2017, 10:53:01 PM
I have been working with NekoSensei offline on this.  What we have learned:
- This activity was traced to a known malicious spammer
- The session problems were caused by special UTF8 characters in the search field
- The problems went away when NekoSensei rewrote the ban messages in English (all ISO-8859-1, no UTF8)

The true underlying problem is that searches for strings with multi-byte UTF8 characters cause session issues.  It appears the spammer was searching the site for his/her ban message (which is why the issues went away when NekoSensei changed the ban messages).   

However, you can still reproduce all the symptoms by searching for multi-byte strings.  A bug has been logged for this.   

Note that the search works fine; the message is logged in the background & the session is rebuilt in the background.  There is no user impact, just worrisome entries in the error log. 

Thanks to NekoSensei for being patient & providing all sorts of helpful info.



Thank you for identifying this.
"If everybody is thinking alike, then somebody is not thinking." - Gen. George S. Patton Jr.

Colin

shawnb61

Quote from: Arantor on December 31, 2017, 07:28:51 AM
Try changing the @ini_set('session.serialize_handler', 'php'); to @ini_set('session.serialize_handler', 'php_serialize');

Requires PHP 5.5.4

Thanks, I'll put this suggestion in the issue log.
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

NekoSensei

I am happy to have been able to help you, I am available for other additional tests.

I thank shawnb61 who took care of my strange case.

albertlast

You could change the code line like mention and
look if the error keeps.

NekoSensei

Hi albertlast,
Are you talking about this?
Quote from: Arantor on December 31, 2017, 07:28:51 AM
Try changing the @ini_set('session.serialize_handler', 'php'); to @ini_set('session.serialize_handler', 'php_serialize');

Requires PHP 5.5.4
Where do I find this line?

Arantor

Probably in Load.php (it's in Session.php in 2.1 but that file didn't exist in 2.0 and I don't know where it is offhand)

Note that you should probably clear the smf_sessions table after doing so.

NekoSensei

this line no exist in load.php in my 2.0.15 smf

I have these lines :
// Attempt to start the session, unless it already has been.
function loadSession()
{
global $HTTP_SESSION_VARS, $modSettings, $boardurl, $sc;

// Attempt to change a few PHP settings.
@ini_set('session.use_cookies', true);
@ini_set('session.use_only_cookies', false);
@ini_set('url_rewriter.tags', '');
@ini_set('session.use_trans_sid', false);
@ini_set('arg_separator.output', '&');

if (!empty($modSettings['globalCookies']))
{
$parsed_url = parse_url($boardurl);

if (preg_match('~^\d{1,3}(\.\d{1,3}){3}$~', $parsed_url['host']) == 0 && preg_match('~(?:[^\.]+\.)?([^\.]{2,}\..+)\z~i', $parsed_url['host'], $parts) == 1)
@ini_set('session.cookie_domain', '.' . $parts[1]);
}




// Use database sessions? (they don't work in 4.1.x!)
if (!empty($modSettings['databaseSession_enable']) && @version_compare(PHP_VERSION, '4.2.0') != -1)
{
session_set_save_handler('sessionOpen', 'sessionClose', 'sessionRead', 'sessionWrite', 'sessionDestroy', 'sessionGC');
@ini_set('session.gc_probability', '1');
}
elseif (@ini_get('session.gc_maxlifetime') <= 1440 && !empty($modSettings['databaseSession_lifetime']))
@ini_set('session.gc_maxlifetime', max($modSettings['databaseSession_lifetime'], 60));



// We want to be able to figure out any errors...
@ini_set('track_errors', '1');


But no @ini_set('session.serialize_handler', 'php');

Arantor


NekoSensei

Like these ?


// Attempt to change a few PHP settings.
==> @ini_set('session.serialize_handler', 'php');
@ini_set('session.use_cookies', true);

Advertisement: