Feature #53813
closedDifferent redirects for different error types in "Page not found" handling
0%
Description
It would be great if the TYPO3 core would have a more detailed "Page not found" handling.
It should redirect to a different page depending on the type of error (FE login required or 404).
A use case:
In a TYPO3 6.1 site, the creation of restricted (fe_groups) pages should be made as easy as possible for editors. There's not one single protected area, but several protected pages all over the pagetree.
So whenever a page has some login behaviour/restriction and no valid fe_user is logged in, it would be great to have a redirection to a central login page with a felogin form.
I have discussed this with Lorenz on [1] and I see it's quite a major issue. But still: this would make a great feature for the next LTS...
Updated by Urs Braem about 11 years ago
PS Sorry the correct link to stackoverflow is
http://stackoverflow.com/questions/20093651/in-typo3-6-1-how-to-define-redirect-page-for-protected-pages/
Updated by Markus Klein about 11 years ago
- Subject changed from Different redirects for different error types to Different redirects for different error types in "Page not found" handling
Updated by Mathias Schreiber almost 10 years ago
- Status changed from New to Closed
that's what config.linkAccessRestricedPages is there for :)
Updated by Stefan Neufeind almost 10 years ago
@Mathias: Really? I read it so that depending on the reason of non-availability different kinds of redirectors should be done - like differentiating between a page that does not exist, has been deactivated or is available but not for you (access-restricted).
Updated by Mathias Schreiber over 9 years ago
Redirect on Access Restriction: -> linkAccessRestricedPages
Redirect on 404 -> pageNotFoundHandling
I don't get the usecase, sorry.
Please rephrase more verbose.
Updated by Mathias Schreiber over 9 years ago
- Status changed from New to Needs Feedback
- Assignee set to Mathias Schreiber
Updated by Lorenz Ulrich over 9 years ago
@ Mathias: Use case: Whenever a page is requested that points to a hidden, not existing or access restricted page, there should be a non-hacky way to determine whether the page really wasn't found or if the page is found, but the current fe_user doesn't have enough permissions.
Currently, we do it that way:
<?php use TYPO3\CMS\Core\Utility\GeneralUtility; class user_pageNotFound { /** * Detect language and redirect to 404 error page * * @param array $params "currentUrl", "reasonText" and "pageAccessFailureReasons" * @param \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController $tsfeObj */ public function pageNotFound($params, $tsfeObj) { $pageUid = GeneralUtility::_GP('id'); if (!empty($params['pageAccessFailureReasons']['fe_group']) && !empty($pageUid)) { // page access failed because of missing permissions header('HTTP/1.0 403 Forbidden'); $this->initTSFE(1); // TODO make configurable $loginPid = 5404; /** @var \TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer $cObj */ $cObj = GeneralUtility::makeInstance('TYPO3\\CMS\\Frontend\\ContentObject\\ContentObjectRenderer'); $loginUrl = $cObj->typoLink_URL(array( 'parameter' => $loginPid, 'useCacheHash' => FALSE, 'forceAbsoluteUrl' => TRUE, 'additionalParams' => '&redirect_url=' . $params['currentUrl'] )); TYPO3\CMS\Core\Utility\HttpUtility::redirect($loginUrl); } else { // page not found // get first realurl configuration array (important for multidomain) $realurlConf = array_shift($GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['realurl']); // look for language configuration foreach ($realurlConf['preVars'] as $conf) { if ($conf['GETvar'] == 'L') { foreach ($conf['valueMap'] as $k => $v) { // if the key is empty (e.g. default language without prefix), break if (empty($k)) { continue; } // we expect a part like "/de/" in requested url if (GeneralUtility::isFirstPartOfStr($params['currentUrl'], '/' . $k . '/')) { $tsfeObj->pageErrorHandler('/index.php?id=' . $GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling_redirectPageID'] . '&L=' . $v); } } } } // handle default language $tsfeObj->pageErrorHandler('/index.php?id=' . $GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling_redirectPageID']); } } /** * Initializes a TypoScript Frontend necessary for using TypoScript and TypoLink functions * * @param int $id * @param int $typeNum */ protected function initTSFE($id = 1, $typeNum = 0) { \TYPO3\CMS\Frontend\Utility\EidUtility::initTCA(); if (!is_object($GLOBALS['TT'])) { $GLOBALS['TT'] = new \TYPO3\CMS\Core\TimeTracker\NullTimeTracker; $GLOBALS['TT']->start(); } $GLOBALS['TSFE'] = GeneralUtility::makeInstance('TYPO3\\CMS\\Frontend\\Controller\\TypoScriptFrontendController', $GLOBALS['TYPO3_CONF_VARS'], $id, $typeNum); $GLOBALS['TSFE']->sys_page = GeneralUtility::makeInstance('TYPO3\\CMS\\Frontend\\Page\\PageRepository'); $GLOBALS['TSFE']->sys_page->init(TRUE); $GLOBALS['TSFE']->connectToDB(); $GLOBALS['TSFE']->initFEuser(); $GLOBALS['TSFE']->determineId(); $GLOBALS['TSFE']->initTemplate(); $GLOBALS['TSFE']->rootLine = $GLOBALS['TSFE']->sys_page->getRootLine($id, ''); $GLOBALS['TSFE']->getConfigArray(); if (\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::isLoaded('realurl')) { $rootline = \TYPO3\CMS\Backend\Utility\BackendUtility::BEgetRootLine($id); $host = \TYPO3\CMS\Backend\Utility\BackendUtility::firstDomainRecord($rootline); $_SERVER['HTTP_HOST'] = $host; } } }
Updated by Mathias Schreiber over 9 years ago
So 3 pageNotFoundHandlers or is this about the information, the pageNotFoundHandler gets passed?
This is what I don't get.
"A non hacky" way could mean so many things.
To me, the current implementation is "non-hacky".
You have a method you can register and get all the data you want.
I do understand that you want something other than that, but I have trouble understanding what exactly :)
Updated by Urs Braem over 9 years ago
As OP, I hope I can clarify the use case (I don't fully understand the depths of the code-related discussion though).
I want to do the following:
- on pages that contain access restricted Content Elements
- if a user is not logged in with the equivalent fe rights
- display a login form ON that page to allow users to log in and see restricted CEs
- And I want to do it with a global setting (e.g. via TypoScript)
So I could tell editors:
"You can create access restricted content wherever you like. If a user is not logged in, instead of the content, a login form will be displayed. Easy, isn't it?"
Details: Why?
- access restricted CEs -> easier to handle than access restricted pages, and a popular use case ("members please log in to see all data")
- form on page instead of redirect -> more stable than the "referer" handling of felogin
My current workaround:
I've just inserted felogin plugins wherever I need them... but that doesn't give the editors the desired flexibility, and creating the forms by themself is too complex
Updated by Urs Braem over 9 years ago
Ah sorry Matthias and Lorenz, I see that above I was talking about restricted pages, not about restricted CEs.
Probably because a solution is closer.
The use case is the same: being able to tell the editors "You can create access restricted pages wherever you like. If a user is not logged in, instead of the content, a login form will be displayed. Easy, isn't it?"
I don't understand what the relation with config.linkAccessRestrictedPages should be. According to http://docs.typo3.org/typo3cms/TyposcriptReference/Functions/Typolink/Index.html this is a boolean setting that allows TYPO3 to output links to access restricted pages instead of discarding them.
PS: maybe the mistake with that ticket is that I tried to formulate it from a technical POV instead as a simple feature request
Updated by Urs Braem over 9 years ago
Here's the imaginary TS I was looking for: a condition to detect if there is content with restrictions on the current page (would not work for page restrictions of course)
// nesting conditions workaround // http://coding-journal.com/working-around-nested-conditions-in-typoscript/ temp.loginform = CONTENT [loginUser = *] temp.loginform = ... // get felogin form [else] temp.loginform = [global] // if there are access restrictions for page or content on that page [restrictedContentOnPage = true] temp.dynamic_loginform < temp.loginform [global]
Updated by Alexander Opitz about 9 years ago
- Category set to Frontend
- Status changed from Needs Feedback to New
- Assignee deleted (
Mathias Schreiber) - Target version set to 8 LTS
Updated by Daniel Siepmann almost 9 years ago
We have updated the provided code: https://github.com/phluzern/adfc_pagenotfound/pull/2
It's now more readable: https://github.com/web-vision/adfc_pagenotfound/blob/master/Classes/Userfunction/PageNotFound.php And works with 6.2 (tested).
Also tested with felogin redirect mechanism.
Updated by Riccardo De Contardi over 7 years ago
- Target version changed from 8 LTS to 9.0
Updated by Moritz Ahl about 7 years ago
- Related to Bug #82848: Wrong cache-control headers when accessing restricted pages added
Updated by Markus Klein about 6 years ago
- Related to Bug #86346: Hidden pages sent 403 Header added
Updated by Denis Mir about 6 years ago
- Priority changed from Should have to Must have
I can't believe such a basic feature "redirect to login page when accessing an access restricted page" is still not part of the TYPO3 core and will not make it in 9 LTS either. This is a basic feature in every other web framework I have worked with over the years and it is absolutely bad UX to show a 404 page when the user reloads the access restricted page. The correct behavior would be to redirect to the login page. (as every other website does it in its user areas)
config.typolinkLinkAccessRestrictedPages = 29
config.typolinkLinkAccessRestrictedPages_addParams = &return_url=###RETURN_URL###&pageId=###PAGE_ID###
The TS above does not fix the the problem since it just refers to the typolink rendering process. But normally (standard UX) you don't render links to access restricted pages but you hide them when the user is not logged in. (you just show the non access restricted login link)
Updated by Hagen Gebauer over 5 years ago
Denis Mir wrote:
I can't believe such a basic feature "redirect to login page when accessing an access restricted page" is still not part of the TYPO3 core and will not make it in 9 LTS either. This is a basic feature in every other web framework I have worked with over the years and it is absolutely bad UX to show a 404 page when the user reloads the access restricted page. The correct behavior would be to redirect to the login page. (as every other website does it in its user areas)
I fully agree. And IMHO this shouldn’t be a project wide configuration in LocalConfiguration.php but page settings in connection with the access restriction page settings. For example: I run a public website with several restricted areas:
/ --> public (including many subpages)
/intranet --> restricted to Intranet user group
/restricted-xyz --> restricted to another user group
The /intranet
root page contains the login form and some content to be displayed when logged in. It contains publicly available subpages such as /intranet/terms-and-conditions
. The restricted pages again are all subpages of /intranet/pages
for which I set the access rights to the Intranet user group and marked extendToSubpages
– this makes sure, no site administrator can forget to access restrict newly added pages.
The way to go should be: For each page that has an access restriction configured in the page settings (rather than for content elements), you should be able to set a redirect to a login page – in the regular backend form for page settings. This redirect should always happen when someone calls the page without being logged in. And that behaviour, obviously, must be extended to subpages as well, in case a page in the rootline is restricted and has the extendToSubpages
flag set.
Updated by Georg Ringer over 4 years ago
- Status changed from New to Closed
With the site handling and the new error handling this is all possible.
Check out the extension https://github.com/plan2net/sierrha which also takes care about redirecting to the login page + url to come back to the page after login
Updated by Hagen Gebauer over 4 years ago
Georg Ringer wrote:
With the site handling and the new error handling this is all possible.
Check out the extension https://github.com/plan2net/sierrha which also takes care about redirecting to the login page + url to come back to the page after login
Thank you for your notes. Does “new error handling” refer to T3v10? I run T3v9LTS in its latest security update. And in the site/error handling form I can still only set different errorHandlers for different errorCodes. That is a step into the right direction as I can at least show a generic page for “403 Forbidden” that links the different login pages instead of showing my default 404 page.
Do I overlook anything? Is this about Custom Page Error Handlers? Can I use these to provide a way to redirect to different login pages depending on the called page in the URL?