[11-Jul-2024 18:39:09 UTC] PHP Warning: Undefined array key "sessiontoken" in /home/*******/public_html/store/includes/system/versioned/1.0.8.1/form.php on line 107
[11-Jul-2024 18:39:09 UTC] PHP Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /home/*******/public_html/store/includes/system/versioned/1.0.8.1/form.php on line 107
line 107 of form.php in versioned/1.0.8.1 (from 102-110) is:
I don't think there has been any recent changes in this area, that could affect functionality.
I tested on the 1.09.5 that I am currently working on;
enter admin
delete admin user
- I am automatically logged off with the "create first administrator" change to usual login page
I created an admin user.
I logged in.
Therefore all good.
I did the same steps in a 1.0.9.0;
Same result. All good.
I presume you now have an admin area that you cannot access ?
I am not here to build for you.
I am here to build with you. Let's help each other.
[11-Jul-2024 18:39:09 UTC] PHP Warning: Undefined array key "sessiontoken" in /home/*******/public_html/store/includes/system/versioned/1.0.8.1/form.php on line 107
[11-Jul-2024 18:39:09 UTC] PHP Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /home/*******/public_html/store/includes/system/versioned/1.0.8.1/form.php on line 107
Am I right in understanding that in line 107 of form.php in versioned/1.0.8.1 :
the sessiontoken (is that the password) is not there causing null to being passed to parameter #1
The question would be why would it not be there?
Nothing has been changed it was all working up until BT changed my IP address which got an auto block to deny me access to my site and after sorting that the login no longer worked
Current Store is now running 1.0.9.0 - php 8.2.18 Now working on taking a short rest - php 8.2.18
Xpajun wrote: ↑Fri Jul 12, 2024 4:39 pm
(is that the password)
No. That's the Cross-Site Request Forgery (CSRF) token. I could try to explain the purpose of that in depth, but my past experiences with explaining it to non-developers lead me to believe that it's a lost cause. Non-technically and shallowly, it's the thingie that checks if someone is using Javascript to hijack your admin session.
My quick thought is that I'd try truncating the session table in phpMyAdmin. Since this will mess with both admin and retail sessions, best to do it at a time when not many customers are logged in. Looking at the whos_online table in phpMyAdmin might help with that. When it's empty go ahead and truncate.
Xpajun wrote: ↑Fri Jul 12, 2024 4:39 pm
(is that the password)
My quick thought is that I'd try truncating the session table in phpMyAdmin. Since this will mess with both admin and retail sessions, best to do it at a time when not many customers are logged in. Looking at the whos_online table in phpMyAdmin might help with that. When it's empty go ahead and truncate.
I've truncated the sessions table and still have the same problem (actually I've truncated it numerous times it doesn't half fill up quick)
burt wrote: ↑Sat Jul 13, 2024 10:02 am
You might also try it in a different browser, as this would create a new session.
Have tried this as well - same result - also tried it on my iPad on sim card to bypass my BT IP address with the same result
It is only the admin on my live store that is doing this I can log in to my test store admin with no problem, the only difference was that my test store doesn't have .htpassword (the whole test store is .htpassword protected) so i removed the .htpassword on my live store admin which hasn't made a difference either
Current Store is now running 1.0.9.0 - php 8.2.18 Now working on taking a short rest - php 8.2.18