[#26861] - Error: Failed to start application: Failed to start application
- Closed
- 12 Nov 2022
- Medium
- Build: staging
- # 26861
Steps to reproduce the issue
Delete user row from #_users table.
Expected result
User should be presented with something more user friendly, a la "User account removed, please reg-register".
Actual result
User session data is persisted in his/her browser, so on next page load, the user is presented with a blank page with the error:-
Error: Failed to start application: Failed to start application
System information (as much as possible)
Joomla 3.9.8.
Additional comments
Here's the stack which is causing this to be thrown:-
"#0 /var/www/html/libraries/src/Log/Logger/MessagequeueLogger.php(48): Joomla\CMS\Factory::getApplication()
#1 /var/www/html/libraries/src/Log/Log.php(320): Joomla\CMS\Log\Logger\MessagequeueLogger->addEntry(Object(Joomla\CMS\Log\LogEntry))
#2 /var/www/html/libraries/src/Log/Log.php(166): Joomla\CMS\Log\Log->addLogEntry(Object(Joomla\CMS\Log\LogEntry))
#3 /var/www/html/libraries/src/User/User.php(888): Joomla\CMS\Log\Log::add('JLIB_USER_ERROR...', 16, 'jerror')
#4 /var/www/html/libraries/src/User/User.php(946): Joomla\CMS\User\User->load('633')
#5 [internal function]: Joomla\CMS\User\User->__wakeup()
#6 /var/www/html/libraries/src/Session/Session.php(670): unserialize('O:24:"Joomla\Re...')
#7 /var/www/html/libraries/src/Session/Session.php(620): Joomla\CMS\Session\Session->_start()
#8 /var/www/html/libraries/src/Session/Session.php(498): Joomla\CMS\Session\Session->start()
#9 /var/www/html/libraries/src/Factory.php(257): Joomla\CMS\Session\Session->get('user')
#10 /var/www/html/libraries/src/Application/CMSApplication.php(153): Joomla\CMS\Factory::getUser()
#11 /var/www/html/libraries/src/Application/CMSApplication.php(760): Joomla\CMS\Application\CMSApplication->checkSession()
#12 /var/www/html/libraries/src/Application/CMSApplication.php(135): Joomla\CMS\Application\CMSApplication->loadSession()
#13 /var/www/html/libraries/src/Application/SiteApplication.php(66): Joomla\CMS\Application\CMSApplication->__construct(NULL, NULL, NULL)
#14 /var/www/html/libraries/src/Application/CMSApplication.php(344): Joomla\CMS\Application\SiteApplication->__construct()
#15 /var/www/html/libraries/src/Factory.php(143): Joomla\CMS\Application\CMSApplication::getInstance('site')
#16 /var/www/html/index.php(51): Joomla\CMS\Factory::getApplication('site')
#17 {main}"
"#0 /var/www/html/libraries/src/Exception/ExceptionHandler.php(62): Joomla\CMS\Factory::getApplication()
#1 [internal function]: Joomla\CMS\Exception\ExceptionHandler::render(Object(Exception))
#2 {main}"
Error: Failed to start application: Failed to start application
The issue I can see here is the "user" still has a valid php session in their browser. Decoding the session file on the server, I can see that the user in this instance was user ID "633", which I had deleted from the #_users table via an external script.
Looking into various methods on how I can catch this before the error is thrown, probably ideally in my situation by just destroying the users session, but seems my options may be limited without the new onBeforeExecute event in v4? Looks like I'm in a similar situation as reported in #10903
joomla-cms-bot
- | Labels |
Added:
?
|
||
Better yet. Don't delete the users table
I don't delete the users table; I delete individual rows upon certain events - there is no way around that in this case. Also, for what it's worth, I am instantiating Joomla and deleting the user row via the delete() method:-
$user = JFactory::getUser($row->user_id);
$user->delete();
as you are in 3.x you can delete all sessions for the user account as well
Truthfully, I don't think you can do anything "user friendly" with this condition. Essentially the problem boils down to unserializing the session data runs into an error with some of the data inside of it. If you tried to do some kind of basic error handling for the condition you'd end up in a really awkward state:
- At the point the error is occurring, the session isn't actually started yet if I'm reading the stack trace right, it's somewhere inside of PHP's
session_start()function - Trying to catch an exception here is asking for trouble, because the reason for the exception can be pretty wide (unserialization issue such as this one, an issue communicating with the session data store (database, filesystem, a cache engine using a network connection), etc. etc.)
- If you did catch an exception, the logical thing would be to try and start a new session, but this only works if you've got the unserialization issue as most other issues would persist if you tried to start a new session
I think this is a case of "it sucks but this is the least sucky of the available options"
Truthfully, I don't think you can do anything "user friendly" with this condition. Essentially the problem boils down to unserializing the session data runs into an error with some of the data inside of it. If you tried to do some kind of basic error handling for the condition you'd end up in a really awkward state:
- At the point the error is occurring, the session isn't actually started yet if I'm reading the stack trace right, it's somewhere inside of PHP's
session_start()function- Trying to catch an exception here is asking for trouble, because the reason for the exception can be pretty wide (unserialization issue such as this one, an issue communicating with the session data store (database, filesystem, a cache engine using a network connection), etc. etc.)
- If you did catch an exception, the logical thing would be to try and start a new session, but this only works if you've got the unserialization issue as most other issues would persist if you tried to start a new session
I think this is a case of "it sucks but this is the least sucky of the available options"
That's kind of where I was leading. I've whittled this down to being caused by a call to JSession::checkToken(), therefore, I've implemented getToken(true) and then re-validate on the new token, which appears to prevent this error at least; what other troubles it'll cause remains to be seen but at least for now it appears to be working smoothly.
Quy
- | Labels |
Added:
J3 Issue
|
||
So... I was about to write that this is a wont-fix and tough luck, you have to take care of this yourself. Then I looked into this further and sigh we have to fix this. Simply said, the code to clear the session is doing this badly. Joomla writes the user ID, username and the session ID to the database, regardless of the used session storage and it does so both in J3 and J4. We are deleting the entries in the sessions table in the "User - Joomla" plugin in the onAfterDeleteUser event with a simple query and that actually sucks. We actually have to get all session IDs assigned to a user from the session table, then load the sessions for all those IDs and call a destroy() on them, then delete all those entries from the table. I actually think with the current setup of our session system, we have to add something like a "delete storage based on a given ID" method to implement this. This would have to be fixed in J3 and J4. And now that I've shown how to fix that, I will leave the glory of actually doing the code to someone else.
zero-24
- | Labels |
Added:
No Code Attached Yet
J4 Issue
Removed: J3 Issue ? |
||
Look like the issue was sorted elsewhere (there were some PRs dealing with session handling sessions in the past). I just tried again with latest Joomla 4.2 and it is working well. After user being deleted, refresh shows him as guest/not logged in user.
As this issue is not valid anymore, I'm closing this. Feel free to re-open if you can still re-procedure the issue with latest Joomla 4.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-11-12 09:49:14 |
| Closed_By | ⇒ | joomdonation |
Better yet. Don't delete the users table