Project

General

Profile

Actions

Bug #92068

closed

Epic #92636: felogin bug collection

felogin (extbase) redirect from GET/POST is not working properly

Added by Rémy DANIEL over 3 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
felogin
Target version:
-
Start date:
2020-08-21
Due date:
% Done:

100%

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

Description

Take a felogin form (the new one of TYPO3 v10 made with Extbase)
Add it to a /login page with the following flexform settings:

Redirect modes:
- Defined by GET/POST parameter
- After login
Check "Use First Supported Mode from Selection"
Set a page from your page tree in "After Successful Login Redirect to Page"

With those settings, I expect two things:

A. I access directly the /login page, I should see the login form.
Then I log in and I should be redirected to the page set in "After Successful Login Redirect to Page"

B. I access a restricted page /private-page with a non logged-in user.
Now TYPO3 should trigger a 403 error, and my custom PageErrorHandler should redirect me to /login?redirect_url=/private-page
Now I should see the login form.
Then I log in, and should be redirected to /private-page

On TYPO3 v10.4.6, the scenario B is not working.
The ?redirect_url=/private-page GET parameter is not propagated to the <input hidden name="redirect_url">,
so the redirect_url is lost when the form is posted.

This scenario used to work with the pi_base version in v9.


Files

fe_login-debug.jpg (65.4 KB) fe_login-debug.jpg Simone Hamm, 2020-09-11 12:14

Related issues 4 (0 open4 closed)

Related to TYPO3 Core - Bug #91844: felogin Redirect to referer is not working at all with Site config 403 errorHandlerClosed2020-07-23

Actions
Related to TYPO3 Core - Bug #96813: BeforeRedirectEvent is not useful at all because it accepts no arguments and the return value is ignoredResolved2022-02-10

Actions
Related to TYPO3 Core - Bug #90157: missing possibility to send return_url Parameter with 403 standard errorhandlerClosed2020-01-20

Actions
Related to TYPO3 Core - Epic #96814: Totally broken felogin redirect mechanismClosed2022-02-10

Actions
Actions #1

Updated by Oliver Hader over 3 years ago

  • Status changed from New to Needs Feedback
Actions #2

Updated by Rémy DANIEL over 3 years ago

This option typolinkLinkAccessRestrictedPages does not influence the way felogin handle the return_url/redirect_url GET parameter.
It just allows typolink to link access restricted page with the add of the return_url/redirect_url GET parameter.

The bug I describe resides in felogin and is a regression introduced with the extbase refactoring of the plugin.

Actions #3

Updated by Simone Hamm over 3 years ago

I have exactly the same configuration with the same problem. In v9 everything works fine.
Attached is a screenshot of the debug output.

Actions #4

Updated by Markus Klein over 3 years ago

  • Parent task set to #92636
Actions #5

Updated by Chris W about 3 years ago

I can confirm this problem in TYPO3 10.4.12

A q&d workaround: /typo3/sysext/felogin/Classes/Controller/LoginController.php

- 'redirectURL' => $this->redirectHandler->getLoginFormRedirectUrl($this->configuration, $this->isRedirectDisabled()),
+ 'redirectURL' => $this->redirectHandler->getLoginFormRedirectUrl($this->configuration,TRUE),

Actions #6

Updated by Wolfgang Klinger about 3 years ago

The problem is simple to explain:
there's this condition in \TYPO3\CMS\FrontendLogin\Controller\LoginController::initializeAction

if ($this->isLoginOrLogoutInProgress() && !$this->isRedirectDisabled()) {

which fails (no login, just a redirect to the login form) and then LoginController::loginAction calls
'redirectURL' => $this->redirectHandler->getLoginFormRedirectUrl($this->configuration, $this->isRedirectDisabled()),

which only handles the configured after login URL and not the also configured get/post parameter (or any other mode).

Actions #7

Updated by Patrick Lenk about 3 years ago

I can also confirm this issue and not working scenario B. I use the extension pagenotfoundhandling with additional get param redirect_url=###CURRENT_URL###. The extbase felogin hidden form element is not filled anymore with TYPO3 10.4 and there is no redirect after login to the login protected page.

Actions #8

Updated by Christian Futterlieb about 3 years ago

Just noticed, that /login?return_url=/private-page works as expected, while redirect_url doesn't (as stated above). hth

Actions #9

Updated by Markus Klein almost 3 years ago

  • Subject changed from felogin redirect from GET/POST is not working properly to felogin (extbase) redirect from GET/POST is not working properly
Actions #10

Updated by Patrick Lenk over 2 years ago

This issue still exists with TYPO3 10.4.17. Any news here? thanks

Actions #11

Updated by Patrick Lenk over 2 years ago

This issue still exists with TYPO3 10.4.21. Any news here? thanks

Actions #12

Updated by Harald Witt over 2 years ago

  • Priority changed from Should have to Must have

There are actually two problems mixed together. I'll try to explain.

1st problem:
The first problem is, that the redirection to the login page does not take place.

2nd Problem:
Felogin should redirect to a referer after login if configured so. But it doesn't do so although return_url is set as a GET-parameter.

Solution for the 2'nd problem:
The example in in the documentation of felogin and also in the DOC of the CONFIG-object is old or at least not valid for the login-fluid-template. Simply have a look at the login template.

<f:if condition="{referer}!=''">
    <f:form.hidden name="referer" value="{referer}" />
</f:if>

The old return_url is now better called as referer. So the following works perfect:
www.your-domain.de/login?referer=WhereYouWantToGotoAfterLogin

Greetings
Harald

Actions #13

Updated by Patrick Lenk over 2 years ago

Harald Witt wrote in #note-12:

...
The old return_url is now better called as referer. So the following works perfect:
www.your-domain.de/login?referer=WhereYouWantToGotoAfterLogin
...

The referer works, but the redirect_url still does not work. So scenario B is not working with TYPO3 10.4.22.
(The ?redirect_url=/private-page GET parameter is not propagated to the <input hidden name="redirect_url">)

Actions #14

Updated by Julian Mair over 2 years ago

This issue still exists in TYPO3 10.4.22. No updates here?

Actions #15

Updated by Daniel Janek about 2 years ago

This issue still exists in TYPO3 11.5.4

Actions #16

Updated by Stefan P about 2 years ago

  • Related to Bug #91844: felogin Redirect to referer is not working at all with Site config 403 errorHandler added
Actions #17

Updated by Stefan P about 2 years ago

This is a fundamental problem. The core 403 error handler does not take any core login-redirect mechanisms into account (be it redirect_url, return_url or referer, be it GET or POST - all is just dropped).

Actions #18

Updated by Stefan P about 2 years ago

The felogin redirect handler \TYPO3\CMS\FrontendLogin\Redirect\RedirectHandler does this:

    protected function getLoginRedirectUrl(array $redirectModes, int $redirectPageLogin): string
    {
        if ($this->isRedirectModeActive($redirectModes, RedirectMode::LOGIN)) {
            return $this->redirectModeHandler->redirectModeLogin($redirectPageLogin);
        }
        return $this->getGetpostRedirectUrl($redirectModes);
    }

As soon as the Flexform has mode "login" configured at all (mode "login" = take the page from the flexform), it ALWAYS wins. this is what the if-condition says. No matter what else is in the list, no matter if the checkbox for the first found method is set or not.

This is just plain wrong. Why have the priority list and the checkbox at all if an hardcoded value just wins always?

As soon as I remove mode "login" from the flexform selection the redirecting works fine. But I don't want to remove it. Because users that just directly go to the login page (no POST/GET/referer) should as a fallback get to the site configured in the Flexform.

Oh, If I remove redirect mode "login" and have NO GET/POST variable, then actually logging in (athenticating) just stops working. ":)"

If I XCLASS this RedirectHandler and just remove the whole if condition then everthing works.

Actions #19

Updated by Stefan P about 2 years ago

  • Related to Bug #96813: BeforeRedirectEvent is not useful at all because it accepts no arguments and the return value is ignored added
Actions #20

Updated by Stefan P about 2 years ago

  • Related to Bug #90157: missing possibility to send return_url Parameter with 403 standard errorhandler added
Actions #21

Updated by Stefan P about 2 years ago

  • Related to Epic #96814: Totally broken felogin redirect mechanism added
Actions #22

Updated by Torben Hansen about 2 years ago

The getLoginFormRedirectUrl function is actually wrong here. This function is providing the redirectURL variable which is used in Fluid template to handover the given redirect URL exclusively for GET/POST redirect evaluation. The function should not take any other configured redirect modes into account. The handling of configured redirects actually happens in the processRedirect function, which respects the configured redirect mode order.

Actions #23

Updated by Gerrit Code Review about 2 years ago

  • Status changed from Needs Feedback to Under Review

Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/73585

Actions #24

Updated by Gerrit Code Review about 2 years ago

Patch set 1 for branch 11.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/73784

Actions #25

Updated by Gerrit Code Review about 2 years ago

Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/73785

Actions #26

Updated by Torben Hansen about 2 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #27

Updated by Benni Mack over 1 year ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF