Bug #100715
closedEpic #92636: felogin bug collection
felogin redirect mode by http referer is not working
Added by Marvin Müller over 1 year ago. Updated about 1 month ago.
100%
Description
The http referer redirect method for felogin with version v11.5.24 is working fine. Unfortunately, after updating to version v11.5.25 or v.11.5.26 the referer redirect method is not working any more. After logging in the user is getting redirected to a totally different page based on the other lower defined redirect methods. The referer method is ranked highest. After downgrading to version v11.5.24 everything is working as expected again and the http referer page will displayed after logging in.
This issue was tested on different local typo3 instances, all with a similar setup (debian bullseye, apache v2.4.56, php7.4, typo3 with composer setup).
Files
clipboard-202307021250-e8yc0.png (23.1 KB) clipboard-202307021250-e8yc0.png | Torben Hansen, 2023-07-02 10:50 |
Updated by Chris Müller over 1 year ago
- Related to Bug #100197: Remove HTTP_REFERER validity check or logging added
Updated by Marvin Müller about 1 year ago
I tried to verify whether or not the validity check prohibits the redirect to the referer. So, I installed the recent version and debugged v11.5.27. Somehow the validity check does prohibit to redirect to the referer url - but not in the way I was thinking. The RedirectUrlValidator->isValid() returns false, because an empty string is provided to be checked.
Why the empty string was provided was figured out quite fast when looking to the stack:- login is handled successfully:
RedirectHandler.php:158, TYPO3\CMS\FrontendLogin\Redirect\RedirectHandler->handleSuccessfulLogin()
: all good - redirectModeReferrer was selected correctly:
RedirectModeHandler.php:144, TYPO3\CMS\FrontendLogin\Redirect\RedirectModeHandler->redirectModeReferrer()
: all good - calling
RedirectModeHandler.php:230, TYPO3\CMS\FrontendLogin\Redirect\RedirectModeHandler->getReferer()
: within this function an empty referer was received from the serverRequestHandler, more specificallyRedirectModeHandler.php:228, $requestReferer = (string)$this->serverRequestHandler->getPropertyFromGetAndPost('referer');
returns an empty string - verifying the url to redirect to:
RedirectUrlValidator.php:50, TYPO3\CMS\FrontendLogin\Validation\RedirectUrlValidator->isValid()
: all good, but the empty string was provided from one step before
Next I was checking my http request within the browser: The http header includes an absolute referer url, according to RFC 2616 14.36. Also typo3 received the referer: The TYPO3\CMS\Core\Http\ServerRequest object has the attribute ['headers']['referer']0 and shows the correct referer url. Nevertheless, this value is never beeing accessed for determining the referer url to redirect after login.
Updated by Marvin Müller about 1 year ago
- Related to Bug #91844: felogin Redirect to referer is not working at all with Site config 403 errorHandler added
Updated by Marvin Müller about 1 year ago
similar to the solution of bug #91844 there should be also fallback option to use the http referer the extbase approach:
https://forge.typo3.org/projects/typo3cms-core/repository/1749/revisions/ac629148b6ce0cc10ae7a85ab1af13d4c7410855
Updated by cosmoblonde GmbH about 1 year ago
Hi,
I can confirm this bug. When is a solution expected?
Or can anyone supply a patch for this problem?
Thanks you!
Updated by Markus Klein about 1 year ago
- Related to Bug #100772: Disabling of referer redirect via redirectReferrer flag is not persisted on login failure added
Updated by Markus Klein about 1 year ago
Maybe the patch for #100772
https://review.typo3.org/c/Packages/TYPO3.CMS/+/78884
is related and helps with this?
Please test it and vote.
Updated by Wesley Richards about 1 year ago
Hello all,
I would like to confirm this bug as well. The redirect via referer after the FE login is the default behavior for protected pages for us and it would be nice if the bug would be fixed.
Thanks in advance
Wesley
Updated by Marvin Müller about 1 year ago
At least I implemented a workaround in the frontend using the felogin 'getpost' redirect mode. It is not a very nice approach, but at least it is working for my case and I want to share the approach with you:
- I have added two html tags to the hidden section of the felogin login form:
<f:form.hidden name="referer" value="" /> <f:form.hidden name="redirectReferrer" value="off" />
- I included the following javascript on the login page setting the referer:
$(document).ready(function(){ // dont set referer when user requesting the normal login page (containing a felogin login form) if($(location).attr('pathname') == "/login"){ return; } // dont set referer when user requesting the normal error-403 page (containing a felogin login form) if($(location).attr('pathname') == "/error/403"){ return; } // set referer // maybe you have to adapt this expression as my login form is already customized $("form.login > fieldset > div.felogin-hidden > input[name='referer']").val( $(location).attr('href') ); });
Security Notes
In the backend the domain of the redirect url will be verified. So, users trying to exploit this redirect should not be redirected to foreign domains.
Updated by Markus Klein about 1 year ago
- Related to Bug #99920: Referer redirect broken after update to 11.5.23 added
Updated by Markus Klein about 1 year ago
- Status changed from New to Accepted
- Assignee set to Markus Klein
- Priority changed from Should have to Must have
The faulty behaviour seems to be related to #99920.
Updated by Torben Hansen about 1 year ago
I did a lot of testing with the fix of the HTTP redirect patches. To me, the current state seems to be the way it should work and worked previously in the legacy felogin-plugin. HTTP referer is evaluated when the login form is rendered. A valid HTTP referer is passed as value of a hidden input field to the login form and submitted back to the server when logging in. If the plugin is configured to respect the HTTP referer and if the HTTP referer is the first entry and if the first supported mode should be used , then the HTTP referer is used for the redirection. I just tested this in TYPO3 11.5.27 and it seems to work as expected.
Can all reporters please verify the following:
1) Required Login Template fields present
The following code must be present in the Login.html
template
<div class="felogin-hidden"> <f:form.hidden name="logintype" value="login"/> <f:form.hidden name="pid" value="{storagePid}"/> <f:if condition="{redirectURL}!=''"> <f:form.hidden name="redirect_url" value="{redirectURL}" /> </f:if> <f:if condition="{referer}!=''"> <f:form.hidden name="referer" value="{referer}" /> </f:if> <f:if condition="{redirectReferrer}!=''"> <f:form.hidden name="redirectReferrer" value="off" /> </f:if> <f:if condition="{noRedirect}!=''"> <f:form.hidden name="noredirect" value="1" /> </f:if> </div>
2. Redirect first method checked
If the login form is configured to support multiple redirect modes, it is suggested to check the following setting
If the setting is omitted, the last matching redirect mode is processed and a possible HTTP referer being the first entry in the redirect mode list will be skipped, if following redirect modes result in a valid redirect URL.
Updated by Markus Klein about 1 year ago
- Status changed from Accepted to Needs Feedback
- Assignee changed from Markus Klein to Torben Hansen
Updated by Marvin Müller about 1 year ago
thanks for putting work into debugging :)
In the meantime I have upgraded to felogin v11.5.28 and I have deactivated all individual customizations. Furthermore, I have enabled the option redirectFirstMethod and I made the redirect method by referer the only option. The mentioned fields of the Login.html template are present.
Unfortunately, I can still confirm this issue still remains. When beeing logged out and accessing a restricted website, I am getting redirected to the defined error 403 page containing the feform login template. When logging in with an authorized user, I am not getting redirected to any page and will stay on this error 403 page and the logged in username will be displayed (instead of the login form).
Are there any specific variables or code lines I should check?
Updated by Markus Klein about 1 year ago
Something I noticed only now in your new description: The login form is placed on an error-page and not a regular page, right?
The difference is that an error-page is actually fetched by an internal sub-request, so this can make a difference.
Updated by Marvin Müller about 1 year ago
Yes, you are right. The login form is placed on the error 403 page. Sorry that I did not mention it before.
Updated by cosmoblonde GmbH about 1 year ago
Same setup for us: the login form is on a page which is defined as 403 error-page
Updated by Torben Hansen about 1 year ago
Summary of our analysis:
If the login plugin is configured to respect the HTTP referrer for redirection, it has to be ensured, that the submission of wrong login credentials does not change the original referrer. Therefore, the original HTTP referrer is passed as hidden input field `referer` to the login form. This is how the ext:felogin legacy plugin handled it and this has been fixed with #91844 and #99920
If the login plugin is located on a page which is used as 403 page, TYPO3 performs a subrequest to the page with the login form, when an access protected page is accessed without an active user session. The original HTTP referrer will be passed to the subrequest and will be evaluated after successful login. Before #99920, the current HTTP referrer was evaluated, which was the referrer of the subrequest and which was wrong in terms of if the plugin is not used in combination with a subrequest (submission of wrong credentials will break HTTP referrer redirection).
So from the current point of view, ext:felogin plugin HTTP referrer redirect evaluation should behave as following:
1) Plugin with HTTP referrer redirect mode on a page which is used in subrequest context: The current HTTP referrer (from the login request) must always be used for the redirect The request URL invoking the subrequest has to be used as HTTP referrer variable in the template
2) Plugin with HTTP referrer redirect mode on page (without subrequest): The HTTP referrer from the original request (submitted as `referer` POST variable) must be used for the redirect
For scenario 1, the plugin should know, if it is called by a subrequest and ignore the HTTP referrer evaluation at a first step (not pass the referrer as `referer` variable to fluid) or use the URI of the access protected page (which initiated the subrequest) as HTTP referrer variable.
Updated by Gerrit Code Review about 1 year 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/+/79704
Updated by Gerrit Code Review about 1 year ago
Patch set 2 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/+/79704
Updated by Gerrit Code Review about 1 year ago
Patch set 3 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/+/79704
Updated by Torben Hansen about 1 year ago
- Related to Bug #90157: missing possibility to send return_url Parameter with 403 standard errorhandler added
Updated by Gerrit Code Review about 1 year ago
Patch set 4 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/+/79704
Updated by Gerrit Code Review about 1 year ago
Patch set 1 for branch 12.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/+/79785
Updated by Gerrit Code Review about 1 year 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/+/79786
Updated by Torben Hansen about 1 year ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset ac1e816567a00225d89b56720eb8767c2852f17f.
Updated by Gerrit Code Review about 1 year ago
- Status changed from Resolved to Under Review
Patch set 2 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/+/79786
Updated by Gerrit Code Review about 1 year ago
Patch set 3 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/+/79786
Updated by Gerrit Code Review about 1 year ago
Patch set 4 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/+/79786
Updated by Torben Hansen about 1 year ago
- Status changed from Under Review to Resolved
Applied in changeset 3570b028e8d0c140634f31feadf1c8b9cb2fff6d.
Updated by Marvin Müller about 1 year ago
Hello Torben,
thanks for putting so much effort in it and for providing a patch. I just installed the latest version v11.5.29 where the patch is also included. I have disabled all customizations again and checked referer mode was ranked highest. I was a bit suprised the redirect was not working. In the felogin-hidden section of the login form no referer was set. Unfortunately, I did not have much time for further debugging. Is there anything specific I should check?
Updated by Torben Hansen about 1 year ago
@Marvin Müller Please verify, that the "Subrequest page Error" Feature toggle is enabled in TYPO3. The fix will only work with the feature toggle active (disabled in v11 by default).
Updated by Marvin Müller about 1 year ago
Thanks a lot @Torben Hansen
I did not noticed that feature toggle. It is working as expected - thank you.
Updated by Torben Hansen 5 months ago
- Related to deleted (Bug #100772: Disabling of referer redirect via redirectReferrer flag is not persisted on login failure)