Bug #93189
closedscheduler conflicts with argon2 password hashing
0%
Description
Hey there,
it's my first bug report here in the forum, so please tell me if I'm doing anything wrong over here.
My problem is the following. I have a typo 3 10.4 version running and I used the argon2 password hashing which worked fine at the beginning (I tested both argon2 versions and everything following appears for both of those versions). After I leave my system as it is for about one day I can't log into the backend anymore. Going into the install tool and adding a new admin user doen't work either, the only way it works to get access again is if I set the password hashing to bcrypt in the install tool and then create a new admin user. All other user account still do not work (their argon2 passwords are not automatically converted to bcrypt). I can then log in with the new admin user and change the user passwords of all other users manually and everything works again, but with bcrypt now. From here on I can switch again to argon2 and everything starts again like described above, it first works, until I leave the system alone.
Now the only thing that was running in the meantime while I was not logged into the system is the CronJob/Scheduler. It could be that a specific task is breaking things, but I would not know which one, for reference I list all the used tasks down below.
Now one thing that I noticed is, that the cli user that is automatically generated by the cron job has a bcrypt password, no matter if I have general password hashing set to argon2 or not, so I thought maybe that would break things. I tried to change the cli password manually which I probably should not do and it also did not work, because i got a php Memory allocation error.
Two more side notes here. The scheduler does not break things if it runs via CronJob while I am logged in, it only happens if I am logged out of the backend. And if this is important, my CronJob does not run with cli, but with cgi-fcgi.
Sorry for this long report, I don't really know what the problem is, maybe someone knows if that bcrypt cli password is wanted behaviour or not.
Thanks for any help, in the meantime I am successfully running on bcrypt, everything works here.
This is a list of my used scheduler tasks:
Caching framework garbage collection (scheduler), File Abstraction Layer: Update storage index (scheduler), File Abstraction Layer: Extract metadata in storage (scheduler), Table garbage collection (scheduler), Anonymize IP addresses in database tables (scheduler), Optimize MySQL database tables (scheduler), Execute console commands (scheduler), staticfilecache:boostQueue, Execute console commands (scheduler) cleanup:orphanrecords, Execute console commands (scheduler), cleanup:deletedrecords, Gelöschte Datensätze entfernen (recycler), Execute console commands (scheduler), form_to_database:deleteFormResults, Fileadmin garbage collection (scheduler)
Files
Updated by Christian Kuhn almost 4 years ago
- Status changed from New to Needs Feedback
Thanks for the report.
This sounds really odd and I'd be interested in the root cause.
If you suspect the cgi-fcgi based scheduler tasks to be the issue, would you maybe try to narrow this down? Like disabling half of them, see if it's gone, then the other half? Are you sure your php setup is ok, so same versions are used on cli and web calls?
Updated by Benny Bachmann almost 4 years ago
Thanks for your answer. I currently have a lot of work to do and I'm still updating my custom extensions to work with typo 3 10.4, after I finish this I will set up a test server to perform some tests and find a solution and I will report here or ask further questions ;) This will be probably in two weeks (end of January).
Updated by Benny Bachmann almost 4 years ago
- File TYPO3 Exception.html TYPO3 Exception.html added
Alright, I'm sorry for the late answer and my probably confusing situation, but I'm really struggling a bit since updating to typo3 10. First of all I reported this issue, as I was not able to connect it to any of the logs. After working my way through the log information and solving everything, I solved a mistake in the typoscript template, the error message was:
[ERROR] request="0a6b2aa159de3" component="TYPO3.CMS.Frontend.Configuration.TypoScript.ConditionMatching.ConditionMatcher": Expression could not be parsed. - {"expression":"globalVar = TSFE : beUserLogin > 0] && [globalVar = GP:debug = 1"}
After solving this the above reported issue seemed to disappear (altough I still don't understand why this influences the be login in such a drastic way), nevertheless a different error appeared. After 2-3 Weeks of a stable performance the website was not reachable anymore with the information "Could not write log record to log file", full exeption attached. After deleting the typo3temp folder everything works again, until the logger finds its way down into the error again.
Until now I have always been able to solve upcoming issues without reporting here, but since the last update I encounter errors, that appear after a random period of time where the site was stable and online, which makes it hard for me to debug or solve the problems as I don't know too much about the typo3 core functionalities and how exactely they work and furthermore the issues disappear as I move the site the my testenvironment and I can't debug it on the production server as this is needed to be online for business. I'm thankful for any help and I apologize for any confusion information here, I am confused :/
Thanks a lot for any help.
Updated by Christian Kuhn over 3 years ago
Hey, I hope you were able to sort out some of the issues meanwhile. This really sounds odd and kinda smells like an unrealibale hosting environment, so this is the area I'd look into in your situation.
I'm unsure on how core development could help currently, it currently looks as if there is nothing we could improve on our side with given information.
I'd tend to close the issue for now if this is ok with you.
Maybe the #typo3-cms slack channel could help with some insights, I'd suggest to reach out for the helpful persons over there.
Updated by Benny Bachmann over 3 years ago
Yes, you can close this issue, thanks a lot for your help and support. You are right that the hosting environment is kind of unreliable at the moment as I still run into other inconsistent problems with Cron-Job Processes, so I will switch hosting as soon as I prepared everything for it. Thanks for your feedback and your ideas.
Updated by Christian Kuhn over 3 years ago
- Status changed from Needs Feedback to Closed
thx 4 feedback. closing.