TYPO3 Core

My current workaround is this:

Extend \TYPO3\CMS\Core\Error\PageErrorHandler\PageContentErrorHandler and use it as :

  -
    errorCode: '403'
    errorHandler: PHP
    errorContentSource: 't3://page?uid=123'
    errorPhpClassFQCN: 'Vendor\Package\AccessDeniedPageContentErrorHandler'

Override handlePageError in there and alter the resolved url like this:

$parsedUrlParts = \parse_url($resolvedUrl);
$resolvedUrl .= (isset($parsedUrlParts['query']) ? '&' : '?') . 'referer=' . \urlencode((string)$request->getUri());

Other use cases may need other changes to the url, this one is working for referer mode of felogin.

Markus Klein wrote:

The PageContentErrorHandler makes an internal request to the specified page, hence there is of course no referrer.

The feature you would like to have is presumably
https://docs.typo3.org/m/typo3/reference-typoscript/10.4/en-us/Setup/Config/Index.html#typolinklinkaccessrestrictedpages

felogin: loginMode=referer does not use HTTP Referer header... It uses an URL parameter named "referer" which the core could append for sure (see my workaround, I exactly do this). The core error handler does not append it. TYPO3 8 did this, however. That's the bug (see description and my current workaround).

felogin is pure core. We upgraded from 8 to 9 and loginMode=referer stopped working (without any config change on our side). What further information is needed here? v9 just broke this feature.

And what does typolinkLinkAccessRestrictedPages has to do with this issue? I already build links to access restricted pages. That's the whole story behind this issue (a user clicks on a access restricted link to get redirected back to it after login - that's promised core functionality).

The bug is that felogin expects a GET parameter that the core does not deliver anymore.

There it is documented:
https://docs.typo3.org/c/typo3/cms-felogin/9.5/en-us//LoginMechanism/RedirectModes/Index.html#defined-by-referrer

Okay, I obviously misunderstood your report then.

Can you please describe the setup that is needed to reproduce the issue?
So felogin config, plugin settings, requested page where the redirect to the login is expected, error handler config that does the redirect, and so forth.
Thanks.

felogin: loginMode=referer does not use HTTP Referer header...

citing from the source code of v8 $referer = $this->referer ? $this->referer : GeneralUtility::getIndpEnv('HTTP_REFERER');

The setup is easy:

• Have a menu pointing to an access restricted page ("access when logged in" or for a specific user group). Totally core.
• Have a the core 403 error handler configured for this site. Totally core
  

      errorCode: '403'
      errorHandler: Page
      errorContentSource: 't3://page?uid=12345'
  

• on this pages.uid=12345 have a felogin plugin, totally core
• configure this plugin in its flexform as redirectMode=referer, totally core
• In the FE be logged out and click on the menu pointing to the restricted page, totally core
• The 12345 with felogin plugin is shown, totally core
• Login, totally core
• TYPO3 8 redirected back to the restricted page (now unrestricted), TYPO3 9 stays on the error page (but being logged in)

The referenced issue #90157 is basically exactly the same, but for loginMode=getpost (it sets the return url by a GET parameter redirect_url which the 403 error handler does not send as well):
https://docs.typo3.org/c/typo3/cms-felogin/9.5/en-us/LoginMechanism/RedirectModes/Index.html#defined-by-get-post-vars

Yes, you are right about the referer, it actually can fall back to HTTP referer. Didn't know this, because in our case it was always the referer parameter. Not sure what the core did to decide between query param or HTTP header when doing the 403 action. But anyways, this is just HTTP: just as you can add a GET paremeter for an "internal" request you could also append any HTTP header (including Referer) to the "internal" request, if you prefer this. HTTP is just a text document in the end.

felogin relies on the core to send specific parameters (either GET or, as I just learned, also HTTP header). TYPO3 9 dropped this without warning.

This bug still exists in 10.4.21
Any progress?

This was probably a "typo". The variable meant is settings.redirectMode from teh flexform, I probably mixed it up in my head with pages.fe_login_mode.

It seems, that this problem still exists in TYPO3 11.

This bug still exists in 10.4.26

Still an issue in TYPO3 11.5.14.

Still an issue in TYPO3 v12.0.0! Why isn't somebody picking this up? I've been waiting very long already...

There is a patch available now. Please test carefully and vote to get the bug fixed.

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/+/77401

The problem reappears for me in a 12.4.1 installation. Can anyone confirm this?

Wolfgang Wagner wrote in #note-33:

The problem reappears for me in a 12.4.1 installation. Can anyone confirm this?

Is this probably the same as #100715?

(I assume at least. There were at least 2 patches for the whole referrer stuff and all went into v11 and v12)