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 <input type="hidden" name="', $context['session_var'], '" value="', $context['session_id'], '" />
, so... what else can be the reason?
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.
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. :-\
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.
create a new file on your server... name it whatever, but most often folks name it phpinfo.php ... paste the following in the file:
<?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.
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.
Thanks a lot for your helping! :) :) :)
1) It was upgraded to 2.0.15.
2) The
phpinfo.php's sessions info:
Quotesession
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
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:
echo '
<input type="hidden" name="hash_passwrd" value="" />
</form>';
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 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..
Quote from: Sir Osis of Liver on June 11, 2019, 07:36:49 PM
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. :(
can you log in if you switch to the curve theme?
Quote from: Illori on June 12, 2019, 11:28:03 AM
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.
@drewactual, I really have it already, but it's not helpful: (https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi66.tinypic.com%2F33dbo69.jpg&hash=f7b4e3a42243e355ecb44dc7da86dd32cc041280). Maybe I should add it to the core theme and to default them too?
it should be present in the default theme already.
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.
Quote from: Sir Osis of Liver on June 12, 2019, 11:34:25 AM
Quote from: Illori on June 12, 2019, 11:28:03 AM
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. :o
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)
I'm telling you the issue is with the social login... disable it. it will have to be unhooked.
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: (https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi68.tinypic.com%2F8x8zlf.jpg&hash=22707850c19c9c657dee9f2953f7b38e4becbfcb). 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."
Quote from: drewactual on June 12, 2019, 01:08:54 PM
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?
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.
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.
As far as I remember, never saw something like this https://www.php.net/manual/en/book.opcache.php
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.
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
...
"
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.
I'm afraid it's too difficult for my present level. :-[ But thank you anyway.
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:
please don't post that much text in one post. it got cut off. create the file so the op can use it.
i tried to use the code bbc and botched it. my bad...
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.
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.
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.
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: (https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi67.tinypic.com%2Fs2co54.jpg&hash=5bd6f03f9292afc8b18308e94c0f0c4566b759b9), 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: (https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi67.tinypic.com%2Fejzsw7.jpg&hash=beff97a28f6d085a8470257caf180efae4dbe804).
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: (https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi66.tinypic.com%2F28gxqf8.jpg&hash=0817d06fd67800639add91bbbb2da89e3fda5ee2).
Update. That thing is also not helping: (https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi64.tinypic.com%2F3500zs4.jpg&hash=415bf03a15d1fe176592947c2f256319e8a34e3e). 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?
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.
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.
Well, okay then. Have to send ticket to the hosting...
QuoteThank 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.
Done. :) If you want to know what was the concrete problem:
QuoteI apologize for any delay you experienced. I've disable litespeed webserver caching. Please check now.
It's OK now.