Project

General

Profile

Actions

Feature #53813

closed

Different redirects for different error types in "Page not found" handling

Added by Urs Braem over 10 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2013-11-20
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

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

[1] http://stackoverflow.com/questions/20093651/in-typo3-6-1-how-to-define-redirect-page-for-protected-pages/


Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #82848: Wrong cache-control headers when accessing restricted pagesClosed2017-10-24

Actions
Related to TYPO3 Core - Bug #86346: Hidden pages sent 403 HeaderClosed2018-09-21

Actions
Actions #2

Updated by Markus Klein over 10 years ago

  • Subject changed from Different redirects for different error types to Different redirects for different error types in "Page not found" handling
Actions #3

Updated by Ernesto Baschny over 10 years ago

  • Target version deleted (6.2.0)
Actions #4

Updated by Mathias Schreiber over 9 years ago

  • Status changed from New to Closed

that's what config.linkAccessRestricedPages is there for :)

Actions #5

Updated by Stefan Neufeind over 9 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).

Actions #6

Updated by Urs Braem over 9 years ago

@Stefan absolutely

Actions #7

Updated by Stefan Neufeind over 9 years ago

  • Status changed from Closed to New

reopening

Actions #8

Updated by Mathias Schreiber almost 9 years ago

Redirect on Access Restriction: -> linkAccessRestricedPages
Redirect on 404 -> pageNotFoundHandling

I don't get the usecase, sorry.
Please rephrase more verbose.

Actions #9

Updated by Mathias Schreiber almost 9 years ago

  • Status changed from New to Needs Feedback
  • Assignee set to Mathias Schreiber
Actions #10

Updated by Lorenz Ulrich almost 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;
        }
    }

}
Actions #11

Updated by Mathias Schreiber almost 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 :)

Actions #12

Updated by Urs Braem almost 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

Actions #13

Updated by Urs Braem almost 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

Actions #14

Updated by Urs Braem almost 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]
Actions #15

Updated by Alexander Opitz over 8 years ago

  • Category set to Frontend
  • Status changed from Needs Feedback to New
  • Assignee deleted (Mathias Schreiber)
  • Target version set to 8 LTS
Actions #16

Updated by Daniel Siepmann over 8 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.

Actions #17

Updated by Riccardo De Contardi about 7 years ago

  • Target version changed from 8 LTS to 9.0
Actions #18

Updated by Moritz Ahl over 6 years ago

  • Related to Bug #82848: Wrong cache-control headers when accessing restricted pages added
Actions #19

Updated by Susanne Moog about 6 years ago

  • Target version deleted (9.0)
Actions #20

Updated by Markus Klein over 5 years ago

  • Related to Bug #86346: Hidden pages sent 403 Header added
Actions #21

Updated by Denis Mir over 5 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)

Actions #22

Updated by Hagen Gebauer almost 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.

Actions #23

Updated by Georg Ringer about 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

Actions #24

Updated by Hagen Gebauer about 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?

Actions

Also available in: Atom PDF