Bug #90733
closed
Backend: LastLoginProvider is no longer stored in the cookie.
0%
Description
Previously, the last used backend login type was stored in the `be_lastLoginProvider` cookie. This cookie still exists, but its value is no longer adjusted if the login provider is changed.
The problem occurs since version 9.5.14 (also in dev-master).
Files
Updated by 
Updated by Claus Due about 4 years ago
A patch was introduced to avoid setting the cookie at all if there is only one login provider. Can you describe more about your use case, most importantly if you have more than one provider?
Updated by Florian Wessels about 4 years ago
Here is the case:
Given are two login providers: the default one and the login provider provided by EXT:auth0 (https://github.com/bitmotion/auth0-for-typo3). The cookie will be set to the value of the default login provider (1433416747). Switching to the auth0 login provider will not update the value of the cookie (see attached screenshot - new value should be 1526966635).
I took a deeper look into the code and the cookie (including the correct) value is delivered in the http response:
Set-Cookie: be_lastLoginProvider=1526966635; expires=Wed, 10-Jun-2020 08:05:11 GMT; Max-Age=7775999; path=/fcg/typo3/; httponly; samesite=strict
But as you can see, the path is wrong. An 'fcg' has crept in, which definitely does not belong here. So the problem results from the constructor of the NormalizedParams class:
$requestHost = 'https://typo310.local';
$scriptName = '/fcgi-bin/php7.2.22.fcgi';
$requestDir = $this->requestDir = $requestHost . GeneralUtility::dirname($scriptName) . '/';
// Value will be: https://typo310.local/fcgi-bin/ which is wrong.
$siteUrl = $this->siteUrl = self::determineSiteUrl($requestDir, $pathThisScript, $pathSite . '/');
// Value will be: https://typo310.local/fcg/
And therefore the cookie is set to the path `/fcg/typo3/` instead of `/typo3/`.
Updated by Claus Due about 4 years ago
Thanks for the quick update! This could be a problem of site configuration or ENV resolving, does not appear to be a cookie problem as such - I'm trying to find out íf any core patches have been introduced which causes the public path of TYPO3 to be resolved incorrectly (on fcgi setups).
Updated by Claus Due about 4 years ago
Small note: it looks like there might be an incorrect assumption in a patch, about what to crop off from the script path in order to end up with the root public path. For example, a fixed input for substr() which does not verify that the cropped off value is, for example, "typo3/".
Updated by Markus Klein about 4 years ago
- Related to Bug #89312: NormalizedParams->getSiteUrl() contains PHP script wrapper added
Updated by Claus Due about 4 years ago
Suspected cause: https://github.com/TYPO3/TYPO3.CMS/commit/045d4dc50f6b93dc6a66116819bc80cc8c046db7
Commit does not list "fcgi-bin" as supported CGI wrapper.
Updated by Claus Due about 4 years ago
Can you provide additional info about your ENV - which httpd, which version, which fcgi-daemon?
Updated by Oliver Hader about 4 years ago
Invalid parts of a CGI wrapper script have been addressed recently in issue #89312.
In case you still experience problems with recent dev-master (TYPO3 v10) having at least 045d4dc50f6b93dc6a66116819bc80cc8c046db7 then please provide the values of $_SERVER for further investigation - as well as the value of PHP_SAPI.
Thanks in advance!
Updated by Florian Wessels about 4 years ago
Check. Works in 9.5.x-dev and dev-master. Thanks for the super-fast replies :)
Updated by Oliver Hader about 4 years ago
- Status changed from New to Closed
Thanks for your feedback. Closing this issue
Updated by Oliver Hader about 4 years ago
Claus Due wrote:
Suspected cause: https://github.com/TYPO3/TYPO3.CMS/commit/045d4dc50f6b93dc6a66116819bc80cc8c046db7
Commit does not list "fcgi-bin" as supported CGI wrapper.
In Apache it is for instance configured like this:
Action php-fcgid /fcgid-bin/wrapper Alias /fcgid-bin/ /opt/local/etc/apache2/fcgid/php72/
Thus, fcgi-bin or fcgid-bin are just the names of the internal alias used to dispatch the actual PHP process using the wrapper script.