Feature #51378
closed
Show a more helpful message if [BE][lockSSL] = 1 and no https is available
100%
Description
During a site upgrade from 4.5 to 6.2, an OTAP configuration was auto-migrated to a LocalConfiguration.php file. This went mostly well, except for the fact that the O (or Development context) does not have SSL enabled.
The BE-lockSSL setting was however set to 1 in the LocalConfiguration.php.
Accessing the TYPO3 backend produced a very unhelpful 404 message.
It took me some time to trace it to the lockSSL.
A more helpful error message would be nice instead of this security by obscurity 404 message.
Updated by Michiel Roos over 10 years ago
- Assignee set to Helmut Hummel
Hi Helmut,
Is it ok to send a forbidden instead of a 404?
Maybe even an extra TYPO3 header explaining a bit more about the mis-configuration?
Kind regards,
Michiel Roos
Updated by Ernesto Baschny over 10 years ago
- Status changed from New to Needs Feedback
- Assignee deleted (
Helmut Hummel)
I do not really understand the issue. This is a misconfiguration in the first place, if you have lockSSL enabled but have not "https" access to the backend available.
The lockSSL does a "blind redirect" to the same requested backend URL but with "https" instead. What happens after that is beyond TYPO3's control. If you've got a "404" it probably means that the "https" server on your machine is configured, but probably pointing to a different VHOST which does not have a TYPO3 backend at that same place (thus a "404").
Did that installation worked before the upgrade?
Updated by Michiel Roos over 10 years ago
The install worked perfectly before.
It is not a misconfiguration.
It't the situation you get into if you attempt a TYPO3 upgrade with a non-standard localconf.php to support a DTAP setup.
Of course I know that I need to create a proper AdditionalConfiguration.php file, but the white screen still had me stumped for a good while.
Updated by Ernesto Baschny over 10 years ago
But where did the "White screen" came from? Could you check the URL that was requested from your webserver to get to this? My reasoning was that TYPO3 cannot do anything there because there is not TYPO3 running at the URL it was redirected to. So what's is your suggestion exactly in this case?
If that was not the problem but instead the "white screen" is some PHP error from TYPO3 (or Exception), please send us more info like contained in the Log file for example.
Updated by Michiel Roos over 10 years ago
The title should read: Show a more helpful message if [BE][lockSSL] = 1 and no https is available
(https instead of http)
The problem is in: typo3/sysext/core/Classes/Core/Bootstrap.php:checkSslBackendAndRedirectIfNeeded
This may also become a problem when moving a development site to a production server where SSL has not yet been set up.
The user is just redirected to the address: 'http://' and gets a 404 header.
Updated by Ernesto Baschny over 10 years ago
- Subject changed from Show a more helpful message if [BE][lockSSL] = 1 and no http is available to Show a more helpful message if [BE][lockSSL] = 1 and no https is available
Updated by Ernesto Baschny over 10 years ago
- Status changed from Needs Feedback to Accepted
So the problem is this branch in the conditions of this method:
// Send Not Found header - if the webserver can make use of it...
header('Status: 404 Not Found');
// Just point us away from here...
header('Location: http://');
This happens if lockSSL is set to "1" (only allow access via SSL).
Indeed this behaviour is sub-optimal, as it doesn't give the user any hint about what's wrong.
BTW, same behaviour we have if "BE>IPmaskList" does not match the users IP.
This has always been like that (code is from Kasper 2003). Nowadays we night throw some meaningful exception or show some more useful error message. Do you have some proposal?
Updated by Michiel Roos over 10 years ago
Some 'Access Denied' message. Check your TYPO3 configuration for errors. Would be nicer than the 404. I would choose Access Denied because that holds for both failing https and the ipmasklist. Then the devs can figure it out further.
If all else fails, they can easily find the cause of the problem by searching the source code for the exception stamp.
Updated by Helmut Hummel over 10 years ago
I would throw a RuntimeException in these places like it is done e.g. in checkLockedBackendAndRedirectOrDie()
Updated by Gerrit Code Review over 10 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26718
Updated by Helmut Hummel over 10 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 5f873f07b7c68b22d130ce7bf73b6cfaba581d20.
Updated by Riccardo De Contardi over 6 years ago
- Status changed from Resolved to Closed