Bug #92068
closedEpic #92636: felogin bug collection
felogin (extbase) redirect from GET/POST is not working properly
100%
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
Updated by Oliver Hader about 4 years ago
- Status changed from New to Needs Feedback
Did define typolinkAccessRestrictedPages
(https://docs.typo3.org/m/typo3/reference-typoscript/master/en-us/Setup/Config/Index.html#typolinklinkaccessrestrictedpages)? If yes, how does it look like?
Updated by Rémy DANIEL about 4 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.
Updated by Simone Hamm about 4 years ago
- File fe_login-debug.jpg fe_login-debug.jpg added
I have exactly the same configuration with the same problem. In v9 everything works fine.
Attached is a screenshot of the debug output.
Updated by Chris W over 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),
Updated by Wolfgang Klinger over 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).
Updated by Patrick Lenk over 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.
Updated by Christian Futterlieb over 3 years ago
Just noticed, that /login?return_url=/private-page
works as expected, while redirect_url
doesn't (as stated above). hth
Updated by Markus Klein over 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
Updated by Patrick Lenk over 3 years ago
This issue still exists with TYPO3 10.4.17. Any news here? thanks
Updated by Patrick Lenk about 3 years ago
This issue still exists with TYPO3 10.4.21. Any news here? thanks
Updated by Harald Witt about 3 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
Updated by Patrick Lenk almost 3 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">)
Updated by Julian Mair almost 3 years ago
This issue still exists in TYPO3 10.4.22. No updates here?
Updated by Daniel Janek almost 3 years ago
This issue still exists in TYPO3 11.5.4
Updated by S P almost 3 years ago
- Related to Bug #91844: felogin Redirect to referer is not working at all with Site config 403 errorHandler added
Updated by S P almost 3 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).
Updated by S P almost 3 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.
Updated by S P almost 3 years ago
- Related to Bug #96813: BeforeRedirectEvent is not useful at all because it accepts no arguments and the return value is ignored added
Updated by S P almost 3 years ago
- Related to Bug #90157: missing possibility to send return_url Parameter with 403 standard errorhandler added
Updated by S P almost 3 years ago
- Related to Epic #96814: Totally broken felogin redirect mechanism added
Updated by Torben Hansen almost 3 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.
Updated by Gerrit Code Review almost 3 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
Updated by Gerrit Code Review over 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
Updated by Gerrit Code Review over 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
Updated by Torben Hansen over 2 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 3503192cb0b62f46dc16d0a843fbe13ddb63fa09.