Simple Machines Community Forum

Hi all !
Since i updated to 2.0.14 i have any same error in my error log , it's not a probleme , i juste always need cleaning ...

Those errors come only, I think, from the aggressiveness of access of spams bots
Those errors never come from members of the forum.

Is there a way to stop seeing these errors?

Here are the errors:

Quotehttps: / /...
2: session_start(): Failed to decode session object. Session has been destroyed
File: /home/lpdm/public_html/v3/Sources/Load.php
Line: 2574


2565: // Use cache setting sessions?
2566: if (empty($modSettings['databaseSession_enable']) && !empty($modSettings['cache_enable']) && php_sapi_name() != 'cli')
2567: {
2568: if (function_exists('mmcache_set_session_handlers'))
2569: mmcache_set_session_handlers();
2570: elseif (function_exists('eaccelerator_set_session_handlers'))
2571: eaccelerator_set_session_handlers();
2572: }
2573:
==>2574: session_start();
2575:
2576: // Change it so the cache settings are a little looser than default.
2577: if (!empty($modSettings['databaseSession_loose']))
2578: header('Cache-Control: private');
2579: }


Those IP from bots spam are not in error log, they come anytime and are banned ( in the admin Ban area )

I never see those error before, i use SMF 2 since december 2011

My other info :
Votre version du forum: SMF 2.0.14
Version courante de SMF: SMF 2.0.14
Version de GD: bundled (2.1.0 compatible)
Version MySQL: 10.0.30-MariaDB
Memcached: 1.4.4
XCache: 3.2.0
PHP: 5.6.30
Version du serveur: Apache



Thanks for all :)

hi , what do I have to do to find out what it can be ?  :laugh:

Check your session.save_path in your PHP configuration file (php.ini). Did you just upgrade SMF or did you also do some PHP configuration changes?

hi , thanks :)

session.save_path   : /tmp
only some phpmyadmin sessions are in this directory...

https://www.lepaysdumanga.fr/phpinfo2.php
( i will delete this file later )

I just upgrade 2.0.13 to 2.0.14 , nothing else
I tested this upgrade before in my computer with wamp :) ( but i haven't any spams bot in interne  ;D  )

I checked my parametter in my forum , session are by the database , must i unactivate de session by database ?

any news for me ? it's happen only with some russian spams bot

Nothing is written anywhere in the sessions
I can just see the correspondence between the banned IP and the time of the error ...

In the picture you will see that there is no ip, no sessions ...?
I did not have these worries with 2.0.13

it's this IP for the moment : https://cleantalk.org/blacklists/178.127.187.13 (https://cleantalk.org/blacklists/178.127.187.13)

Good evening, some news about this little problem? thank you :)

I do not know if you have looked at this problem, but I have the impression that there is a bug with the list of banned IPs trying to access and sessions (I banned spam bots ), Can you control at this level?
I'll test the bans options, I'm using partial banning right now. (All checked in partial)
Thank you.

Banning spammers, especially spambots, is a waste of time and system resources.

I have only 105 ip address ranges and all go well on my server, I add no more for several years.

The only problem I have is 2.0.14, I'm testing a change and would tell you what it's like tomorrow.

Can you PM me forum admin, and SSH or ftp credentials. I'll take a look at this during the weekend.

Done, thank you :)

Any News In This Side ? :D
Can we hide this error? Because it bores me only visually...  :D

Hello, this problem still exists with 2.0.15 ;)

Ref: https://github.com/SimpleMachines/SMF2.1/pull/4393

^ Can you try this please.

Hi colin , in this page it's for session.php , remove 2 lines on it which are :


function sessionDestroy($session_id)
{
global $smcFunc;

==> if (preg_match('~^[A-Za-z0-9,-]{16,32}$~', $session_id) == 0)
==> return false;

( https://github.com/SimpleMachines/SMF2.1/pull/4393/commits/c533c6b722fa187d70384322ff2083ec8de1afc7 )

then i try remove those same lines in load.php

I delete them now and I will see I continue to have these errors ;)
thanks

bad news ! i still got the same error !


Aujourd'hui à 23:41
.../index.php?action=search2
2: session_start(): Failed to decode session object. Session has been destroyed
Fichier: .../Sources/Load.php
Ligne: 2575



2575 : session_start();


I see in this other thread:
https://www.simplemachines.org/community/index.php?topic=554833.msg3933477#msg3933477

You were going to try renaming the cookie.  Another user reported that resolved the issue.

Have you done that?   Did the issue come back?

Hello, no rename cookies do not change anything, in fact I noticed that most errors come from some spam servers, these servers go through paths that generate these errors when a guest does not have the right to go without a session (a real guest does not generate an error)

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

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)

For the moment with your 2 requests I get this:

maxlen
3622

minlen
82

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... 

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.

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

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. 

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

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.

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.

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

Requires PHP 5.5.4

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.

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.

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.

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

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?

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.

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');

Put it before the ini_set for cookies.

Like these ?


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


Well, yes, but you want the php_serialize version, that's the newer fixed version.

I emptied the table smf_sessions and applied like this


function loadSession()
{
global $HTTP_SESSION_VARS, $modSettings, $boardurl, $sc;

// Attempt to change a few PHP settings.
@ini_set('session.serialize_handler', 'php_serialize'); // le changement
@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', '&');



Wait and see  ;)

Yup. Should find the problem is gone.

For the moment no error, everything is going very well, we will see in 3 or 4 days, and if all goes well, we can say that it is definitely solved :)

Hello everyone,
After a few days, and following the addition of the line in the loap.php, I am forced to find that everything works perfectly! Thanks again to shawnb61 and Arantor !
There is nothing more in my error page, just password errors of the usual members ...

Now all you have to do is add this line to a possible next patch 2.0.16 ;)

See you :D

Thanks for the info.
I've recently switched to PHP 7 and noticed exactly the same entries i my error log.
Although, I'm not sure if this is related to the new PHP. It's possible they were also on my old 5.6 version but they didn't get my attention.
I will try to add the suggested code to my Load.php file.