Nonstop "Session verification failed. Please try logging out and back in again"

[TheSnake]

Suddenly error messages like "Session verification failed. Please try logging out and back in again, and then try again." and "Your session timed out while posting. Please go back and try again." started to show up anytime when someone (admin, mod or user) trying to log in or log out.

We've got this

Code Select Expand

<input type="hidden" name="', $context['session_var'], '" value="', $context['session_id'], '" />, so... what else can be the reason?

[drewactual]

what are you using for handling sessions?  are you writing to files? if so, check the location and the permissions on that file as your host may have altered it....

if you're using memcached for sessions, check that memcached is operational/working. 

also, make sure every login is using the sessions variable addition/fix. 

[TheSnake]

It's SMF 2.0.15 as it is. We didn't change anything related to sessions, so I suppose it's the SMF 2.0.15 original session handling, which I have no idea what's exactly and how's it working.

[Sir Osis of Liver]

Sounds like your host changed something.  You can try disabling database driven sessions in Admin -> Server Settings, but might be best to contact host support.

[drewactual]

create a new file on your server... name it whatever, but most often folks name it phpinfo.php ... paste the following in the file:

Code Select Expand

<?php

phpinfo();

?>

save it and close it... navigate to it... scroll down to area called 'sessions' and tell us what's in it. 

did you upgrade to 2.0.15 or was it installed as 2.0.15?  again, scour every login script on your page and see if the sessions fix is present. 

[drewactual]

by the way, I notice you use the social login by smfpacks, and... the sessions patch isn't in that script... ask me how I know.  iirc it's a file named 'sociallogin.php' in your default theme.  add the sessions variable to it, or.... abandon that mod as it is too quirky to rely on anyway. 

[TheSnake]

Thanks a lot for your helping!

1) It was upgraded to 2.0.15.

2) The phpinfo.php's sessions info:   

session

Session Support    enabled
Registered save handlers    files user
Registered serializer handlers    php_serialize php php_binary wddx

Directive    Local Value   Master Value

session.auto_start   Off   Off
session.cache_expire   180   180
session.cache_limiter   nocache   nocache
session.cookie_domain   no value   no value
session.cookie_httponly   Off   Off
session.cookie_lifetime   0   0
session.cookie_path   /   /
session.cookie_secure   Off   Off
session.entropy_file   /dev/urandom   /dev/urandom
session.entropy_length   32   32
session.gc_divisor   0   0
session.gc_maxlifetime   1440   1440
session.gc_probability   0   0
session.hash_bits_per_character   5   5
session.hash_function   0   0
session.name   PHPSESSID   PHPSESSID
session.referer_check   no value   no value
session.save_handler   files   files
session.save_path   /var/cpanel/php/sessions/ea-php56   /var/cpanel/php/sessions/ea-php56
session.serialize_handler   php   php
session.upload_progress.cleanup   On   On
session.upload_progress.enabled   On   On
session.upload_progress.freq   1%   1%
session.upload_progress.min_freq   1   1
session.upload_progress.name   PHP_SESSION_UPLOAD_PROGRESS   PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix   upload_progress_   upload_progress_
session.use_cookies   On   On
session.use_only_cookies   On   On
session.use_strict_mode   Off   Off
session.use_trans_sid   0   0

[drewactual]

you're using files... and... you upgraded.  this issue goes back to prior versions where a sessions variable was added- themes not built with this change will behave as you describe.

the happenstance of it just starting is most likely due to a cache expiring... for instance if you have a year set on cache expiration in your htaccess or ini file, it perhaps just expired and checked back in for changes- finding the lack of sessions variable check... and... you get what you got.

so...

in your theme's index.template.php, you should have:

Code Select Expand

echo '
               <input type="hidden" name="hash_passwrd" value="" />
            </form>';

replace it with:

Code Select Expand

echo '
               <input type="hidden" name="hash_passwrd" value="" />
<input type="hidden" name="', $context['session_var'], '" value="', $context['session_id'], '" />
            </form>';

depending on what modifications you have, you're going to want to find where there are login forms... the script change is going to be the same as above for each of them.  as a for instance, that social login has it's script in a file (again IIRC) sociallogin.php...  all of the login scripts need that sessions check added to them, which is generally contained to themes that you ported from versions prior to 2.0.14...

there is also a mod that USED to exist written by Arantor that did this for you to save you the effort of changing code.  I have it, but i hesitate sharing it because he took it down for some reason i'm not privy to... if you want it and after i clear it with him i'll hang it somewhere you can pick it up..

[TheSnake]

Sounds like your host changed something.  You can try disabling database driven sessions in Admin -> Server Settings, but might be best to contact host support.

Thanks for the idea, but the big problem is nobody (nor users, not admins) is able to login in the forum anymore.

[Illori]

can you log in if you switch to the curve theme?

[Sir Osis of Liver]

can you log in if you switch to the curve theme?

/index.php?theme=1

May not work.  If not, you can change it in database.  Set theme_default to 1 in smf_settings.  You can also disable database driven sessions by changing databaseSession_enable to 0 in same table, but don't think that will help.

[TheSnake]

@drewactual, I really have it already, but it's not helpful: . Maybe I should add it to the core theme and to default them too?

[Illori]

it should be present in the default theme already.

[Sir Osis of Liver]

Per your first post, you have the session check in Curve theme.  It has to be added to Core, but wouldn't be causing a problem unless you're using Core theme (are you?).  In any event, it wouldn't just stop working unless you upgraded from earlier version to 2.0.14 or .15.

[TheSnake]

can you log in if you switch to the curve theme?

/index.php?theme=1

May not work.  If not, you can change it in database.  Set theme_default to 1 in smf_settings.  You can also disable database driven sessions by changing databaseSession_enable to 0 in same table, but don't think that will help.

Tried already and the result is: yes, formally the Admin is logged in, but when trying to edit, post, etc. again this: "An Error Has Occurred!
Session verification failed. Please try logging out and back in again, and then try again.", so practically no admin.

[Kindred]

sounds like host-side/corrupted session problems....

using repair_settings.php, change your cookie name and maybe try changing the database driven sessions (either turn it on or off, which ever it is currently not)

[drewactual]

I'm telling you the issue is with the social login... disable it.  it will have to be unhooked.

[TheSnake]

Well, this repair_settings.php I did it already. Once again I tried now, because I'd like to respect every idea you're giving me and to prove it's done: . Sad, but seems it doesn't affect the problem in anyway. Again "An Error Has Occurred!
Your session timed out while posting. Please go back and try again."

[TheSnake]

I'm telling you the issue is with the social login... disable it.  it will have to be unhooked.

I remember it and I want to remove it. As soon as I can get the Admin access. Btw, I don't know, is there some way to remove it from the cpanel?

[drewactual]

do you use OPCache?  you will need to reset it if you do in order to witness changes... you'll also need to clear your local (your computers) cached files for your site to witness the changes depending on how extensively you leverage caches.

[drewactual]

there is a procedure for removing hooks from your database... i can't recall if it is an SQL query or a php script, but somebody will be along shortly to help us with that.... either way, that mod uses a hook to function and that hook has to be set free.

[TheSnake]

As far as I remember, never saw something like this https://www.php.net/manual/en/book.opcache.php

[drewactual]

go back to that phpinfo from before and look for OPCache and it's status... there is also an OPCache management tool you can create that will help you manage what scripts it is 'holding in suspension for reuse' and where you can reset individual files or all of them... if you are in a shared environment, you may not know if you have it running, and, you may not have access to managing it... you'd have to ask your host to reset it for you most likely. 

[TheSnake]

OK, I saw it. Here's what we have:

"Zend OPcache

Opcode Caching   Up and Running
Optimization   Enabled
Startup   OK
Shared memory model   mmap
Cache hits   896
Cache misses   209
Used memory   24458656
Free memory   42636320
Wasted memory   13888
Interned Strings Used memory   3606784
Interned Strings Free memory   587520
Cached scripts   198
Cached keys   211
Max keys   3907
OOM restarts   0
Hash keys restarts   0
Manual restarts   0
Directive   Local Value   Master Value
opcache.blacklist_filename   no value   no value
opcache.consistency_checks   0   0
opcache.dups_fix   Off   Off
opcache.enable   On   On
opcache.enable_cli   Off   Off
opcache.enable_file_override   Off   Off
opcache.error_log   no value   no value
opcache.fast_shutdown   0   0
opcache.file_update_protection   2   2
opcache.force_restart_timeout   180   180
opcache.inherited_hack   On   On
opcache.interned_strings_buffer   4   4
opcache.load_comments   1   1
opcache.log_verbosity_level   1   1
opcache.max_accelerated_files   2000   2000
opcache.max_file_size   0   0
opcache.max_wasted_percentage   5   5
opcache.memory_consumption   64   64
opcache.optimization_level   0xFFFFFFFF   0xFFFFFFFF
opcache.preferred_memory_model   no value   no value
opcache.protect_memory   0   0
opcache.restrict_api   no value   no value
opcache.revalidate_freq   2   2
opcache.revalidate_path   Off   Off
opcache.save_comments   1   1
opcache.use_cwd   On   On
opcache.validate_timestamps   On   On
...
"

[drewactual]

make certain you've unhooked and disabled the social login mod, and after you've changed the cookie name and ran repair_settings, ask your host to reset your OPCache.

Or... you can TRY this- download, and then create a file with the code found at https://github.com/amnuts/opcache-gui ,  and see if you can manage the cache for only your webpage.  if you can, simply clear the cache. 

[TheSnake]

I'm afraid it's too difficult for my present level.  But thank you anyway.

[drewactual]

not too difficult and ye you can... not hard... follow directions:

create a file named opcache.php or whatever you choose and paste this into it:

[Illori]

please don't post that much text in one post. it got cut off. create the file so the op can use it.

[drewactual]

i tried to use the code bbc and botched it.  my bad...

[drewactual]

again- make a file, paste the contents of this file into it (or just upload this file) and navigate to it... it's intuitive, but you're looking for the reset button. 

[Sir Osis of Liver]

You can remove hooks with fix_packages.php, but it will break other hooked mods if you do.  I would uoload clean set of files, run fix_packages, see if that clears the glitch.  You'll have to reinstall any mods you want to continue to use.

[drewactual]

with as many hits as the OPCache is showing, chances are in my opinion he has perhaps solved the original issue but the cache is trapping it.. for instance, load.php has some issue with OPCache often times i have witnessed.. trapping and not updating, and therefor retaining problem scripts in suspension until it is manually cleared and reloaded with the changes.

a matter of fact, his OPCache could easily be holding a corrupted login2 and the issue is that simple.  this is one of the reasons why i have it configured on my primary page to flush files every so often and to (every so often) compare the byte size of files and/or the dates to determine changes and force it to reload.     

[TheSnake]

I'm frankly trying all you suggest. This time I tried fix_packages.php. As far as I haven't admin login (every admin attempt produces that session error thing and there is no more admin control, new users, moderator control, etc.), I decided to try it in that way: , but when tried to access it like that repair_settings.php and phpinfo.php, it's not working (and maybe it's not meant to be), because I got this 404: .

Well, I'm still trying to understand that opache-control thing, but still not able to realize what's that, because right now I'm having this and trying to figure out all I can: .

[TheSnake]

Update. That thing is also not helping: . Tried many times. No result.
(About the browsers. I cleaned all the cookies and stuff. We tried 3 cleaned up browsers -- Firefox, Opera and IE... The same...

The themes -- core, curve -- the same.)

Probably, it's over?

[Sir Osis of Liver]

No, it's not over if your database is intact, you can always rebuild the forum from scratch as long as you have your content.  Do a clean install in different directory, connect it to production database, run repair_settings, see if login works.

[drewactual]

Sir, I apologize.. it was right under my nose from the first of this thread. 

go look at your post listing your sessions values from the php info file..

your probability is zero.
your garbage collection (gc) is also zero.
your sessions cookie value time value is zero.

set them (have your host set them) to at least:
100 (this means 100 out of the value below will be challenged again even if they have valid cookies)
100000 (this is the total pool of ppl with valid cookies to be compared before 'garbage' is collected)
1440 (this is how long the SERVER values cookies/sessions... realize, this isn't exactly 'logged in' but 'recorded as a visitor' as a session begins from the servers perspective as soon as a computer connects to port 80 or port 443... the 1440 is in seconds)

also, the file path is the standard for an install which is fine, but make sure the system can write to the file- permissions and php user based...

in short, this is a hosting issue and you should cut them loose on it after pointing them in the right direction.  I personally wouldn't alter anything more until given the green light by your host.  i wager they did an update or alteration to accommodate another user and it impacted you.

[TheSnake]

Well, okay then. Have to send ticket to the hosting...

[TheSnake]

Thank you for contacting our support team. A support ticket has now been opened for your request. You will be notified when a response is made by email. The details of your ticket are shown below.

Subject: Session errors non-stop. The forum isn't allowing logins.
Priority: Medium
Status: Open

(  Ticket Information
#387997 - Session errors non-stop. The forum isn't allowing logins.
Open
Department
Technical Support
Submitted
14/06/2019 (06:29)
Last Updated
10 hours ago
Priority
Medium)

Still waiting for their response/action.

[TheSnake]

Done. If you want to know what was the concrete problem:

I apologize for any delay you experienced. I've disable litespeed webserver caching. Please check now.

It's OK now.