Session verification failed. Please try logging out and back in again, and then

[Kindred]

Oh, good point.
The user may have to add the setting

[a10]

For an option that wasn't set before, it wouldn't show up in the SQL because it wasn't set and therefore had no value to have been saved.

ah! :O)

[brucegust]

I have added the "securityDisable" variable to the smf_settings table and set it to a value of "0." Still getting the same error message.

Any other ideas?

[Arantor]

Set it to 1.

[brucegust]

Alright! I'm in!

Here's what I've learned up to this point:

When you login, you're triggering the AdminMain function on the Admin.php page. In light of the error being related to a session dynamic, I popped the hood on the "validateSession" function on line #468. That took me to the Security.php page and there within the validateSession function, I found "checkSession."

The checkSession function is on line 647 and it's there where the "session_verify_fail" error is being generated.

I commented all of that out and while I didn't get the error, now, although I was entering my client's correct password, I kept getting told I was using the wrong password to get in. Mind you, I've successfully logged into the site, but I can't get into the admin suite.

It's then that I checked back with the forum and I changed the "securityDisable" setting to 1 and SHAZAM, I'm in!

But I agree with a comment that was made previously. I don't feel like I've fixed anything. Frankly, apart from learning a little bit more about the Simple Machines framework, I feel like I've spent a lot of time barking up the wrong tree.

A couple of follow up questions, if you're willing to indulge me...

Having changed the "securityDisable" setting, does that mean any user can access the Administrative Suite?

Back in April of this year, I told my client that she was going to have to update her site because there were portions of her code that was still using "mysql" as part of her database queries. It became an issue when her server updated their PHP to version 7 and parts of her site ceased to function. Is there something about PHP 7 that doesn't play well with SMF 2.0.7 that I should know about and would that have caused the Session Verification error that wasn't happening until earlier this week?

Just because I want to finish what I started: In the "validateSession" function, you've got the code that's going to validate the person who's clicked on the $_POST['admin_pass'] button. You get this:

$good_password = in_array(true, call_integration_hook('integrate_verify_password', array($user_info['username'], $_POST['admin_pass'], false)), true);

I started to pop the hood on "call_integration_hook" and I get the impression this SM's way of invoking different SQL statements, but where? I kept looking for a basic SELECT that was going to pull from a table - perhaps one that had the word "admin" in its title - but I never found anything. How does SM check login credentials? What tables are used and how does it know the username when they attempt to login to the admin suite and the only thing that's being checked is the password?

Thanks!

[Arantor]

Having changed the "securityDisable" setting, does that mean any user can access the Administrative Suite?

No, it just means that they won't be prompted to re-enter their password once an hour. They still have to have admin permissions.

Is there something about PHP 7 that doesn't play well with SMF 2.0.7

It's amazing it works at all, frankly, because PHP 7 compatibility was only introduced in SMF 2.0.14. But it's also possible that mods are relevant here too.

I get the impression this SM's way of invoking different SQL statements

It really isn't. It's about allowing plugins to change the current state of play at different times. Specifically, the code says 'here I am, at integrate_verify_password, does anyone want to do anything', and if so it would call any plugin that said it wanted to be called, and then move on to the next thing. To verify if this is the case, you can look in the settings table for an entry called 'integrate_verify_password' and see if anything is listed. Almost no mods actually use it so I'd be surprised if you even have the entry, let alone it having anything in it.

What tables are used and how does it know the username when they attempt to login to the admin suite and the only thing that's being checked is the password?

smf_members. How does it know? Because they're already logged in in the first place; if they're not logged in they wouldn't get just the one password box, but a full login prompt. Since it already knows who you are because you're already logged in, it's a trivial enough matter to take the password, re-hash it and compare it to what you have already in the database.

[brucegust]

Alright, my user has texted me and said that while she can get into the Admin suite, she can't really do anything without getting the same error message that she was before.

I'm inclined to think that this is all about compatibility. One of the comments on this thread was to update her entire application. Can I do that from the Admin suite? If so, how?

[m4z]

I think you're looking for Patching.

[Sir Osis of Liver]

You have the access to the database, look in smf_log_errors and see if it's logging any relevant errors.

[brucegust]

Just for the sake of putting an exclamation point on all this, I did get the error fixed by recognizing the fact that the version my client was using was really, really old. I didn't try to upgrade anything. Rather, I did a fresh install of version 15, uploaded the old database and it's working great!

Thanks for your feedback!