Http Redirect 301 prevents browsers from retrieving the correct url after authentication
Hello TYPO3 Core Team
I had an issue with user restricted pages concerning the http status code of the redirect.
The Server sends status 301 and redirects to the configured login page. Status 301 indicates, that the browser may cache the redirect result and may never fetch the original url. So even when correctly authenticated and authorised the user cannot view the page unless he clears the browser cache.
It would be better to use status code 302 in this case, so the browser will try to fetch the original url.
I tracked the issue to file typo3/sysext/cms/tslib/class.tslib_fe.php, line 2788. I changed the status code manually from 301 to 302 ($redirectStatus = t3lib_utility_Http::HTTP_STATUS_302;).
Could you please change the status code or provide the possibility to configure it via typoscript.
#2 Updated by Joonas Kauhanen almost 5 years ago
I can confirm this behaviour. Whenever a frontend user tries to navigate to an access restricted page but is not logged in, a 301 redirect is happening to login page. After logging in, trying to navigate to the initial page will result in a cached redirect by the browser. The suggested patch works but it is maybe not the optimal way. We are using TYPO3 6.1.5 with Realurl on a fairly standard LAMP server.
#7 Updated by Andreas Schosser over 4 years ago
I think I have to clarify the issue.
Let's have a look at the following page structure:
|- parent page (shortcut mode first subpage) |- page 1 (restricted to group 1) |- page 2 (restricted to group 2) |- Login (public) |- common page (restricted to groups 1 and 2)
When an anonymous user access the common page TYPO3 issues a permanent redirect to the Login page. This should be changed to "302 Found".
Our setup us as follows:
- TYPO3 4.7.19
- Realurl 1.12.7
- no postVarSet_failureMode set
#9 Updated by Dmitry Dulepov over 4 years ago
1. RealURL does not handle anything regarding authentication or login because it runs before the page id is known to TYPO3. Without page id it is not possible to redirect anywhere.
2. RealURL does not handle anything regarding permissions to view pages. It only decodes/encodes URLs given to it. It is up to the caller to handle the rest.
3. RealURL always uses a custom HTTP status line to let you know that it is redirected. A typical RealURL redirect produces the following status line:
HTTP/1.0 301 TYPO3 RealURL redirect
So the chance that it is RealURL is 0.001%.
#11 Updated by Andreas Schosser over 4 years ago
What happens if you disable realurl?
The problem persists with config.tx_realurl_enable=0
Is it the same with TYPO3 CMS 6.2?
I haven't tried this setup with 6.2 yet.
301 is not good in most cases, but we've to figure out which component is triggering it, the Core or realurl
I think it's the core becaus my patch of typo3/sysext/cms/tslib/class.tslib_fe.php worked for me an the status code is harcoded there in line 2.788.
#12 Updated by Markus Klein over 4 years ago
- Category changed from felogin to Caching
- Status changed from Needs Feedback to Accepted
- Target version set to next-patchlevel
Ok, I guess I finally understood your problem.
The problem is actually, that you've a shortcut, whose target changes depending on the login state.
For performance reasons we chose to do a permanent redirect, but clearly for this scenario that is not the best idea.
I agree we should use another status code, but not 302, as this one is replaced with 303/307 in HTTP/1.1, see http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
Moreover we will not find enough reviewers for 4.x, so I guess this will be fixed 6.3,6.2 only.