Project

General

Profile

Actions

Bug #100715

closed

Epic #92636: felogin bug collection

felogin redirect mode by http referer is not working

Added by Marvin Müller about 1 year ago. Updated 11 months ago.

Status:
Resolved
Priority:
Must have
Assignee:
Category:
felogin
Target version:
-
Start date:
2023-04-23
Due date:
% Done:

100%

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

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

Related issues 4 (0 open4 closed)

Related to TYPO3 Core - Bug #100197: Remove HTTP_REFERER validity check or loggingClosedTorben Hansen2023-03-17

Actions
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 #99920: Referer redirect broken after update to 11.5.23ClosedTorben Hansen2023-02-10

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

Actions
Actions #1

Updated by Chris Müller about 1 year ago

  • Related to Bug #100197: Remove HTTP_REFERER validity check or logging added
Actions #2

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:
  1. login is handled successfully: RedirectHandler.php:158, TYPO3\CMS\FrontendLogin\Redirect\RedirectHandler->handleSuccessfulLogin(): all good
  2. redirectModeReferrer was selected correctly: RedirectModeHandler.php:144, TYPO3\CMS\FrontendLogin\Redirect\RedirectModeHandler->redirectModeReferrer(): all good
  3. calling RedirectModeHandler.php:230, TYPO3\CMS\FrontendLogin\Redirect\RedirectModeHandler->getReferer(): within this function an empty referer was received from the serverRequestHandler, more specifically RedirectModeHandler.php:228, $requestReferer = (string)$this->serverRequestHandler->getPropertyFromGetAndPost('referer'); returns an empty string
  4. 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.

Actions #3

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
Actions #4

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

Actions #5

Updated by cosmoblonde GmbH 12 months ago

Hi,
I can confirm this bug. When is a solution expected?

Or can anyone supply a patch for this problem?

Thanks you!

Actions #6

Updated by Markus Klein 12 months ago

  • Related to Bug #100772: Disabling of referer redirect via redirectReferrer flag is not persisted on login failure added
Actions #7

Updated by Markus Klein 12 months 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.

Actions #8

Updated by Wesley Richards 12 months 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

Actions #9

Updated by Marvin Müller 12 months 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:

  1. 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" />
    
  2. 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.

Actions #10

Updated by Markus Klein 12 months ago

  • Related to Bug #99920: Referer redirect broken after update to 11.5.23 added
Actions #11

Updated by Markus Klein 12 months 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.

Actions #12

Updated by Markus Klein 12 months ago

  • Parent task set to #92636
Actions #13

Updated by Torben Hansen 12 months 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.

Actions #14

Updated by Markus Klein 12 months ago

  • Status changed from Accepted to Needs Feedback
  • Assignee changed from Markus Klein to Torben Hansen
Actions #15

Updated by Marvin Müller 12 months 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?

Actions #16

Updated by Markus Klein 12 months 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.

Actions #17

Updated by Marvin Müller 12 months ago

Yes, you are right. The login form is placed on the error 403 page. Sorry that I did not mention it before.

Actions #18

Updated by cosmoblonde GmbH 12 months ago

Same setup for us: the login form is on a page which is defined as 403 error-page

Actions #19

Updated by Torben Hansen 12 months 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.

Actions #20

Updated by Gerrit Code Review 12 months 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

Actions #21

Updated by Gerrit Code Review 12 months 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

Actions #22

Updated by Gerrit Code Review 12 months 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

Actions #23

Updated by Torben Hansen 12 months ago

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

Updated by Gerrit Code Review 12 months 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

Actions #25

Updated by Gerrit Code Review 12 months 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

Actions #26

Updated by Gerrit Code Review 12 months 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

Actions #27

Updated by Torben Hansen 12 months ago

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

Updated by Gerrit Code Review 12 months 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

Actions #29

Updated by Gerrit Code Review 12 months 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

Actions #30

Updated by Gerrit Code Review 11 months 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

Actions #31

Updated by Torben Hansen 11 months ago

  • Status changed from Under Review to Resolved
Actions #32

Updated by Marvin Müller 11 months 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?

Actions #33

Updated by Torben Hansen 11 months 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).

Actions #34

Updated by Marvin Müller 11 months ago

Thanks a lot @Torben Hansen
I did not noticed that feature toggle. It is working as expected - thank you.

Actions #35

Updated by Torben Hansen 3 months ago

  • Related to deleted (Bug #100772: Disabling of referer redirect via redirectReferrer flag is not persisted on login failure)
Actions

Also available in: Atom PDF