Project

General

Profile

Actions

Bug #105591

open

ext:felogin does not delete fe_typo_user Cookie on logout

Added by Carl-Fredrik Gustafsson 26 days ago. Updated 25 days ago.

Status:
New
Priority:
Should have
Assignee:
Category:
felogin
Target version:
-
Start date:
2024-11-13
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
12
PHP Version:
8.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

We use felogin for a closed part of our website with redirect mode ‘Defined by GET/POST Parameters’ enabled.

In a newsletter we send out links to the login page with the access protected target page provided as redirect_uri query param.

The two usual cases work fine: If you are already logged in the correctly redirected page is displayed.
If you are not logged in the login page is displayed. After login you get redirected to the deeplinked page.

However: if you recently logged in and out again and then open the deeplink url again, you will incorrectly be redirected to the target page without displaying the login page - a 403 error is thrown.

Deleting the fe_typo_user cookie solves the problem. In TYPO3 v11 the cookie was still deleted after logout, but it seems not to be deleted with TYPO3 v12.

We are currently on TYPO3 12.4.21.


Related issues 6 (6 open0 closed)

Related to TYPO3 Core - Bug #103685: Response headers are not handled according to PSR-7 in extbaseUnder Review2024-04-19

Actions
Related to TYPO3 Core - Bug #103805: Extbase response headers are not cachedNew2024-05-08

Actions
Related to TYPO3 Core - Bug #99032: Multiple Set-Cookie-Headers in Extbase-Responses are not sent to browserNew2022-11-09

Actions
Related to TYPO3 Core - Bug #100488: Broken Response creation in coreNew2023-04-05

Actions
Related to TYPO3 Core - Bug #96294: PageContentErrorHandler ignores configured additionalHeadersNew2021-12-08

Actions
Related to TYPO3 Core - Bug #104828: config.contentObjectExceptionHandler sends 200 HTTP Status and regular cache headersNew2024-09-05

Actions
Actions #1

Updated by Garvin Hicking 26 days ago

  • Assignee set to Torben Hansen
Actions #2

Updated by Benni Mack 25 days ago

The reason for this behavior is that

feUser->setCookie = SetCookieBehaviour::Remove is not applied anymore.

One of the reasons is that EXT:felogin is actually doing a redirect. This means, that LoginController propagates a Extbase Response and sets headers directly via header() - then, our middleware does not set the cookie properly anymore when logging out to remove the cookie (in FrontendUserAuthenticator.php and AbstractApplication.php).

My workaround was to adapt Extbase's Bootstrap.php around line 192ff like this:

if (headers_sent() === false) {
// added by benni
if ($response->getStatusCode() >= 300) {
throw new PropagateResponseException($response);
}
// added by benni
foreach ($response->getHeaders() as $name => $values) {
foreach ($values as $value) {
header(sprintf('%s: %s', $name, $value));
}
}
Actions #3

Updated by Benni Mack 25 days ago

  • Related to Bug #103685: Response headers are not handled according to PSR-7 in extbase added
Actions #4

Updated by Benni Mack 25 days ago

  • Related to Bug #103805: Extbase response headers are not cached added
Actions #5

Updated by Benni Mack 25 days ago

  • Related to Bug #99032: Multiple Set-Cookie-Headers in Extbase-Responses are not sent to browser added
Actions #6

Updated by Benni Mack 25 days ago

  • Related to Bug #100488: Broken Response creation in core added
Actions #7

Updated by Benni Mack 25 days ago

  • Related to Bug #96294: PageContentErrorHandler ignores configured additionalHeaders added
Actions #8

Updated by Benni Mack 25 days ago

  • Related to Bug #104828: config.contentObjectExceptionHandler sends 200 HTTP Status and regular cache headers added
Actions

Also available in: Atom PDF