TYPO3 Core

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.

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']⁰ and shows the correct referer url. Nevertheless, this value is never beeing accessed for determining the referer url to redirect after login.

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

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

Or can anyone supply a patch for this problem?

Thanks you!

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.

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

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.

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?

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.

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

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

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.

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

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

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

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

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

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

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

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?

@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).

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