Project

General

Profile

Actions

Bug #90157

closed

missing possibility to send return_url Parameter with 403 standard errorhandler

Added by Claude Unterleitner over 4 years ago. Updated 7 months ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Link Handling, Site Handling & Routing
Target version:
-
Start date:
2020-01-20
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

With the new site configuration module (since TYPO3 9.5) you can set a 403 error handler and chose a page of the tree by setting "choose content from page", e.g. a login page which will be shown if someone tries to access an access restricted page.

fe_login extension gives the possibility to redirect a user to a restricted page he tried to reach, before he was logged in. This is achieved by a get parameter return_url and setting
config {
typolinkLinkAccessRestrictedPages = <uid of the login page>
typolinkLinkAccessRestrictedPages_addParams = &return_url=###RETURN_URL###
}

see [[https://docs.typo3.org/c/typo3/cms-felogin/master/en-us/Examples/Index.html]]

Unfortunately when using the configuration above for creating a 403 error handler, no parameter return_url is sent, so the user is always redirected to the same welcome page which is defined in the felogin plugin.

My solution was now to use the extension pagenotfoundhandling in which you can define an additional 403 GET param, e.g. ?return_url=###CURRENT_URL###


Related issues 5 (0 open5 closed)

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 #92068: felogin (extbase) redirect from GET/POST is not working properlyClosed2020-08-21

Actions
Related to TYPO3 Core - Bug #96813: BeforeRedirectEvent is not useful at all because it accepts no arguments and the return value is ignoredResolved2022-02-10

Actions
Related to TYPO3 Core - Epic #96814: Totally broken felogin redirect mechanismClosed2022-02-10

Actions
Related to TYPO3 Core - Bug #100715: felogin redirect mode by http referer is not workingResolvedTorben Hansen2023-04-23

Actions
Actions #1

Updated by Henrik Ziegenhain almost 4 years ago

Jep, definitely a missing feature in my eyes - or the documentation of TSref should be updated since the feature got removed.

I solved it with an custum PageContentErrorHandler and rebuild a redirect behavior:
https://typo3.slack.com/archives/C025BQLFA/p1594823553348500?thread_ts=1594821550.346900&cid=C025BQLFA

Actions #2

Updated by Stefan P almost 4 years ago

  • Related to Bug #91844: felogin Redirect to referer is not working at all with Site config 403 errorHandler added
Actions #3

Updated by Markus Klein over 3 years ago

  • Status changed from New to Accepted
  • Priority changed from Should have to Must have
Actions #4

Updated by Stefan P over 2 years ago

  • TYPO3 Version changed from 9 to 10

Updating to v10, since 9 is dead, bug is still present and very annoying.

Actions #5

Updated by Benni Mack over 2 years ago

  • Status changed from Accepted to Needs Feedback

Is this related to EXT:felogin or the Error Handling configuration?

Actions #6

Updated by Claude Unterleitner over 2 years ago

it's related to Error Handling configuration. The missing redirect can be solved by using a custom PageContentErrorHandler and the referer redirect in EXT:felogin. It would be nice if the Error Handling would be capable of redirecting to a referer without having to use a custom PageContentErrorHandler.

Actions #7

Updated by Stefan P over 2 years ago

  • Related to Bug #92068: felogin (extbase) redirect from GET/POST is not working properly added
Actions #8

Updated by Stefan P over 2 years ago

  • Related to Bug #96813: BeforeRedirectEvent is not useful at all because it accepts no arguments and the return value is ignored added
Actions #9

Updated by Stefan P over 2 years ago

  • Related to Epic #96814: Totally broken felogin redirect mechanism added
Actions #10

Updated by Stefan P over 2 years ago

To sum up all comments:

This is no "missing" feature. It ia silently dropped feature without adjusting documentation: I'd call this an "undocumented" and "breaking" change, a regression.

"Solving" (workaround-hacking) with a custom ErrorHandler class is possible, of course. But it should not be needed to write a custom class, because up to TYPO3 8 this was a core feature that was never officially dropped or un-documented. ext:felogin still has and documents all TS and Flexform settings to configure such redirects, but the redirect/error handlign of the core just fulyl ignores them since v9. (this is true for all redirect modes in FE login since v9, see the linked epic ticket which sums this up).

Actions #11

Updated by Benni Mack over 2 years ago

  • Status changed from Needs Feedback to Accepted

Stefan P wrote in #note-10:

To sum up all comments:

This is no "missing" feature. It ia silently dropped feature without adjusting documentation: I'd call this an "undocumented" and "breaking" change, a regression.

"Solving" (workaround-hacking) with a custom ErrorHandler class is possible, of course. But it should not be needed to write a custom class, because up to TYPO3 8 this was a core feature that was never officially dropped or un-documented. ext:felogin still has and documents all TS and Flexform settings to configure such redirects, but the redirect/error handlign of the core just fulyl ignores them since v9. (this is true for all redirect modes in FE login since v9, see the linked epic ticket which sums this up).

Hi Stefan,

thank you for the summary. Can you provide a patch to fix this?

All the best,
Benni.

Actions #12

Updated by Stefan P over 2 years ago

Benni Mack wrote in #note-11:

thank you for the summary. Can you provide a patch to fix this?

I'd say, the one who dropped the feature should re-implement it so that he learns to not just drop features. :)

(or ask my company if they pay me to invest 2 weeks coding-time for the v12 core while we are not even on v11 with the project where this is relevant, while at the same time being totally busy with programming for the actual customer ;) )

What lead to this situation: cleanup of the HTTP status handling, also for status 403. This is fine. But EXT:felogin should provide an extended version of it that provides the dropped features. Then everyone without felogin has the "clean" version, and everyone with felogin can rely on the old behaviour.

Actions #13

Updated by Benni Mack over 2 years ago

Stefan P wrote in #note-12:

I'd say, the one who dropped the feature should re-implement it so that he learns to not just drop features. :)

OK, will investigate this.

(or ask my company if they pay me to invest 2 weeks coding-time for the v12 core while we are not even on v11 with the project where this is relevant, while at the same time being totally busy with programming for the actual customer ;) )

OK. Can you send me your company's information so I can contact them? You can send me an email with the info at .

Actions #14

Updated by Ayke Halder about 1 year ago

For a backend solution:

TYPO3 11: Error page with fe-login-form might get cached. The cache-identifier is "URL of page with fe-login-form" and not "current request URL resulting in error".
So you can't have different HTML-Code for different request URLs which returns code "403 unauthorized".
https://github.com/TYPO3/typo3/blob/18aaf13ac9f0cf27672e559b5f2a23def52fdffc/typo3/sysext/core/Classes/Error/PageErrorHandler/PageContentErrorHandler.php#L111-L122

TYPO3 12: No caching anymore
https://github.com/TYPO3/typo3/blob/60becc56ba85aa396b944af5093a3d3b487771e5/typo3/sysext/core/Classes/Error/PageErrorHandler/PageContentErrorHandler.php#L82-L84

In TYPO3 11 there is a by default disabled "Feature: #94402 - Generate error pages via TYPO3-internal sub-request"
https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/11.4/Feature-94402-GenerateErrorPagesViaTYPO3-internalSubRequest.html

Since TYPO3 12: This feature is enabled by default.
https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/SiteHandling/ErrorHandling/PageErrorHandler.html

Changed in version 12.0: Error pages are always generated via a TYPO3-internal sub-request instead of an external HTTP request (cURL over Guzzle).

Might be easier to implement a solution via JavaScript in the frontend:

Pseudo code:


IF (ELEMENT EXISTS '.felogin-hidden') {
  IF (NOT ELEMENT EXISTS '.felogin-hidden > input[name="referer"]') {
    APPEND TO ".felogin-hidden" NEW ELEMENT '<input type="hidden" name="referer" value="INSERT_CURRENT_DOCUMENT_URL_FROM_BROWSER">'
  }
}
Actions #15

Updated by Ayke Halder about 1 year ago

This issue might be solved by https://forge.typo3.org/issues/91844 with https://review.typo3.org/c/Packages/TYPO3.CMS/+/77204

and use of:


config {
typolinkLinkAccessRestrictedPages = NONE
}
Actions #16

Updated by Torben Hansen 12 months ago

This should work with #100715 when the felogin plugin is configured to redirect by HTTP referrer and when the plugin is placed on the page which the 403 error handler shows.

Actions #17

Updated by Torben Hansen 12 months ago

  • Related to Bug #100715: felogin redirect mode by http referer is not working added
Actions #18

Updated by Felix Nagel 10 months ago

I'm no longer able to redirect after login when a deep link was requested but use the configured default redirect when the login page is used directly. This was fixed in v11.5.25 with #99920 but is broken again in 11.5.30 (probably even earlier).

I was able to fix this by using something similar to this workaround: https://forge.typo3.org/issues/91844#note-2 but now using with return_url parameter and getpost redirect mode.

Actions #19

Updated by Torben Hansen 7 months ago

  • Status changed from Accepted to Closed

I close this ticket now, since it is planned to implement a new 403 ErrorHandler to TYPO3 which supports ext:felogin redirect_url. Please follow #101252 for progress

Actions

Also available in: Atom PDF