Nonstop "Session verification failed. Please try logging out and back in again" and nobody was able to login!
We've got one of the biggest problems of the history of our Omnilogy forum. Permanent
Nonstop "Session verification failed. Please try logging out and back in again" errors and that's why nobody was able to login here!
It was very depressing, indeed!!!
This is how the problem was resolved.
1. We explained it in the simplemachines.org's community that 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 every time when someone (admins, mods or users) were trying to log in or log out and that we have got this
<input type="hidden" name="', $context['session_var'], '" value="', $context['session_id'], '" />, so... we had no clue what else can be the reason, once we already got that code.
drewactual asked what are we using for handling sessions; are we writing to files? If so, to check the location and the permissions on that file as our host may have altered it. If we're using memcached for sessions, to check that memcached is operational/working. Also, to make sure every login is using the sessions variable addition/fix.
We answered that currently it's SMF 2.0.15 as it is. We didn't change anything related to sessions, so we suppose it's the SMF 2.0.15 original session handling, which we have no idea what's exactly and how's it working.
Sir Osis of Liver said that it sounds like our host changed something and that we can try disabling database driven sessions in "Admin -> Server Settings", but might be best to contact host support.
drewactual said we to create a new file on our server, to name it whatever, but most often folks name it phpinfo.php and to paste the following in the file:
<?php
phpinfo();
?>, then to save it and to close it, to navigate to it, to scroll down to area called 'sessions' and to tell them what's in it. Also there was a question did we upgraded to 2.0.15 or was it installed as 2.0.15? Plus, again, to scour every login script on our page and to see if the sessions fix is present. And, btw, that person noticed that we 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. " We didn't know (or we forgot) that we use something like this.
But we removed the QR login and we disabled the OpenID option, so we hope there will be no problems.
We expressed our thanks a lot (many thanks) for their helping and we answered that
1/ It was upgraded to 2.0.15.
2/ The phpinfo.php's sessions info was:
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 added that we're using files and we upgraded. This issue goes back to prior versions where a sessions variable was added - themes not built with this change will behave as we describe. The happenstance of it just starting is most likely due to a cache expiring; for instance if we have a year set on cache expiration in our htaccess or ini file, it perhaps just expired and checked back in for changes - finding the lack of sessions variable check... and... we get what we got. So in our theme's index.template.php we should have:
echo '
<input type="hidden" name="hash_passwrd" value="" />
</form>'; and to replace it with:
echo '
<input type="hidden" name="hash_passwrd" value="" />
<input type="hidden" name="', $context['session_var'], '" value="', $context['session_id'], '" />
</form>'; depending on what modifications we have, we'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..." We learned that 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...
About the server settings we answered that we thank for the idea, but the big problem is that nobody (neither users, nor admins) is able to login in the forum anymore.
"
Illori asked can we log in if we switch to the curve theme and Sir Osis of Liver added that: /index.php?theme=1
May not work. If not, we can change it in database. Set theme_default to 1 in smf_settings. We can also disable database driven sessions by changing databaseSession_enable to 0 in same table, but doesn't think that will help.
We replied ( to drewactual), that really have it already, but it's not helpful:
. We wondered if we should add it to the core theme and to default them too. And Illori said that it should be present in the default theme already.
Sir Osis of Liver posted that per our first post, we have the session check in Curve theme. It has to be added to Core, but wouldn't be causing a problem unless we're using Core theme (are we?
Yes, we're using three themes currently -- Core, Default and Karanlik Lord). In any event, it wouldn't just stop working unless we upgraded from earlier version to 2.0.14 or .15.
We replied (about the logins) that we 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 (no admins).
Then Kindred said that sounds like host-side/corrupted session problems... and suggested to 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). And drewactual added that telling us the issue is with the social login and to disable it. It will have to be unhooked.
What we replied was that well, this repair_settings.php was done already. Once again we tried, because we'd like to respect every idea they're giving us and to prove it's done:
. Sad, but seemed it doesn't affect the problem in anyway. Again there was an "
An Error Has Occurred!
Your session timed out while posting. Please go back and try again." + we remember it and we want to remove it. As soon as we can get the Admin accesses. By the way, we don't know, is there some way to remove it from the cpanel?...
drewactual asked do we use OPCache and added that we will need to reset it if we do in order to witness changes... we'll also need to clear our local (our computers') cached files for our site to witness the changes depending on how extensively we leverage caches. + That there is a procedure for removing hooks from our database; 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.
Honestly, As far as we remembered, never saw something like this (more about it
https://www.php.net/manual/en/book.opcache.php), because we're not professionals in this field. We know SEO and non-SEO, we know some science, but we're not very familiar with stuff like this.
And then drewactual said to go back to that phpinfo from before and to look for OPCache and its status... there is also an OPCache management tool we can create that will help us manage what scripts it is 'holding in suspension for reuse' and where we can reset individual files or all of them... if we are in a shared environment, we may not know if we have it running, and, we may not have access to managing it... we'd have to ask our host to reset it for us most likely.
Okay, we saw it. And here is what we had:
"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
...
"
The reply was to make certain we've unhooked and disabled the social login mod, and after we've changed the cookie name and ran repair_settings, to ask our host to reset our OPCache.
Or we can TRY thas - to download, and then create a file with the code found at
https://github.com/amnuts/opcache-gui, and to see if we can manage the cache for only our webpage. If we can, simply to clear the cache.
At first it looked difficult to us. We were afraid it's too difficult for our present level.
But thank you anyway!
We were encouraged that it's not too difficult and we can do it... it's not hard if we follow directions: to create a file named opcache.php or whatever you choose and paste the necessary code into that. (and "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 replied that we can remove hooks with fix_packages.php, but it will break other hooked mods if we do. + "I would upload clean set of files, run fix_packages, see if that clears the glitch." And we'll have to reinstall any mods we want to continue to use.
drewactual replied that with as many hits as the OPCache is showing, chances are in his opinion we had perhaps solved the original issue but the cache is trapping it... for instance, load.php has some issue with OPCache often times... trapping and not updating, and therefor retaining problem scripts in suspension until it is manually cleared and reloaded with the changes. And a matter of fact, our OPCache could easily be holding a corrupted login2 and the issue is that simple. This is one of the reasons why he has it configured on his 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.
Well, we didn't get all of this info very well, because we do not understand that much, but we tried:
We were frankly trying all they suggested. This time we tried
fix_packages.php. As far as we haven't admin login (every admin attempt produces that session error thing and there is no more admin control, new users, moderator control, etc.), we 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 we got this 404:
.
Well, then we were still trying to understand that opache-control thing, but still we were not able to realize what's that, because at that time we were having this and trying to figure out all we can:
.
And we did it. It really wasn't that difficult. The update we posted was that that thing is also not helping:
. Tried many times. No result.
(
About the browsers. We 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?" we really wondered. But it wasn't over! Sir Osis of Liver answered that it's not over if our database is intact, we can always rebuild the forum from scratch as long as we have our content -- "Do a clean install in different directory, connect it to production database, run repair_settings, see if login works."
And drewactual said "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."
At last we decided to bother the hosting (we're avoiding to bother people, because we hope to help ourselves alone), so we said "Well, okay then. Have to send ticket to the hosting..." And we sent. Basic info of that ticket:
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)
At that time we were still waiting for their response/action. Then they answered and it was done successfully. 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.
And, as you see now, it's alright already!
Thanks again to all of you, who helped to solve the big session problem!!!
Topic: Forum (Luntan) problems (Read 611789 times)