?
avatar jbjhjm
jbjhjm
27 Feb 2020

Steps to reproduce the issue

Set up a clean Joomla installation (tested with Joomla 3.9.15).
Change database connection in configuration.php so that it fails.

Expected result

Error telling "Database Connection failed"

Actual result

Warning: session_start(): Failed to read session data: user (path: /var/lib/php/sessions) in /usr/share/nginx/www/pub/registrierung/libraries/joomla/session/handler/native.php on line 260
Error: Failed to start application: Failed to start the session

System information (as much as possible)

Current environment: Joomla 3.9.15, PHP 7.1.33
I'm pretty sure this situation occured with other versions, too.

Additional comments

JSessionHandlerNative->doSessionStart does

		// Ok to try and start the session
		if (!session_start())
		{
			throw new RuntimeException('Failed to start the session');
		}

It seems the first database query will be done from within session handler.
When removing throw new RuntimeException('Failed to start the session');, the database connection error will be shown, as it should. Instead, The class thinks the php session is misconfigurated and shows an error which is actually misleading.

avatar jbjhjm jbjhjm - open - 27 Feb 2020
avatar joomla-cms-bot joomla-cms-bot - change - 27 Feb 2020
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 27 Feb 2020
avatar mbabker
mbabker - comment - 27 Feb 2020

PHP doesn’t offer any mechanism to get an error for why a session didn’t start (there’s no json_last_error() for the session API). You might be able to add extra info if there’s a message in error_get_last(), but just flat out removing the Exception throwing from that part of the code is not a valid fix.

(FWIW the message isn’t “entirely misleading”, in context the exception being thrown has a valid message, it just lacks any additional detail about the reason for the exception which is what causes the debugging headache)

avatar jbjhjm
jbjhjm - comment - 27 Feb 2020

PHP doesn’t offer any mechanism to get an error for why a session didn’t start (there’s no json_last_error() for the session API). You might be able to add extra info if there’s a message in error_get_last(), but just flat out removing the Exception throwing from that part of the code is not a valid fix.

(FWIW the message isn’t “entirely misleading”, in context the exception being thrown has a valid message, it just lacks any additional detail about the reason for the exception which is what causes the debugging headache)

My words were misleading. I did not mean to remove the exception, this would be bad indeed.
I see what's the difficulty. However, a failing session_start() is normally related to things like misconfigurations of PHP sessings, and as such this error message would lead to head scratching in some cases.
Wouldn't it make more sense to first establish a database connection (and error if it is misconfigurated) and then start the session?

avatar mbabker
mbabker - comment - 27 Feb 2020

Wouldn't it make more sense to first establish a database connection (and error if it is misconfigurated) and then start the session?

Not necessarily. This only applies if you're using the Joomla default configuration of using the database as a session store (which I wish would change but *shrug*, the filesystem handler is plenty reliable as long as the host config is not FUBAR). And for the same reasons I moved the explicit $session->start() call out of where the session was being created, we don't want an explicit $db->connect() call to happen just because the database object is created. The API is well optimized in the aspect of either I/O operations or network connections for external connections (cache, database, and session) aren't performed until needed, it just ends up that because of order of operations and how PHP handles error stacking that the real error in this case (database connection issue) is getting absorbed and not reported up when the "can't start session" error is being shown. And like I said, error_get_last() may help create a more useful error message here but that's probably still going to be iffy at best.

avatar jbjhjm
jbjhjm - comment - 2 Mar 2020

I see, then the code should stay as it is.
I suggest to extend the thrown error message text to something like:
Failed to start the session (Check PHP session path and database connection if sessions are managed in database.)

avatar jwaisner jwaisner - change - 15 Apr 2020
Status New Expected Behaviour
Closed_Date 0000-00-00 00:00:00 2020-04-15 14:54:23
Closed_By jwaisner
avatar joomla-cms-bot joomla-cms-bot - change - 15 Apr 2020
Status Expected Behaviour Closed
Closed_Date 2020-04-15 14:54:23 2020-04-15 14:54:24
Closed_By jwaisner joomla-cms-bot
avatar joomla-cms-bot joomla-cms-bot - close - 15 Apr 2020
avatar joomla-cms-bot
joomla-cms-bot - comment - 15 Apr 2020

Set to "closed" on behalf of @jwaisner by The JTracker Application at issues.joomla.org/joomla-cms/28109

avatar jwaisner
jwaisner - comment - 15 Apr 2020

Closing as expected behavior at this time.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/28109.

Add a Comment

Login with GitHub to post a comment