Typo3: show login page for protected pages when user not is logged in
The problem: If you have pages which are only accessible for certain FE user groups, some of your users may bookmark these protected pages and return when they are not logged in (or you may send the URLs in a newsletter, etc.). Typo3 handles this case as a “404 Page not found” situation (I don’t know why they think 401/403 and 404 are the same, but I can’t change it).
So if you want to show a login form in this case, but a 404 error page if the page is “really” not there, you have to write a user-defined page-not-found-handling function. I have put it into fileadmin/404.php:
function pageNotFound($param, $ref) {
if (count($param["pageAccessFailureReasons"]["fe_group"])) {
header("HTTP/1.0 403 Forbidden");
$url = LOGIN_URL."?redirect_url=".$param["currentUrl"];
} else
$url = NOTFOUND_URL;
print file_get_contents($url);
}
}
Then set this in your typo3conf/localconf.php:
$TYPO3_CONF_VARS['FE']['pageNotFound_handling'] = 'USER_FUNCTION:fileadmin/404.php:user_pageNotFound->pageNotFound';
Put a felogin content element onto the login page (here: login.0.html) and set the redirect options like to: login,loginGroup,getpost
So, what happens if the user goes to a protected page when (s)he is not logged in?
- Typo3 detects that the page is not accessible and calls our page not found handler.
- The handler detects that it is not a real 404 error but the page is proected and redirects to login.0.html?redirect_url=<original url>
- The user logs on.
- Because getpost is set as a redirect option, the user comes back to <original url>.
Important hint: It took me hours to find out that the redirect options don’t work if the login page has front end user group privileges set. It seems to work only if it’s on a public page.
Also make sure that the LOGIN_URL is found on the system, or you will have a recursive loop calling the 404 page.
Tags: typo3
Free Software, Web Development | rfc2822 | 
October 29, 2009 15:55
Subscribe
Very nice, Richard!
I just implemented your solution in a TYPO3 4.3.2 website using the felogin sysext for logins and I had to change some details to get it working:
1. As I don’t use RealURL or static URLs in this project, my LOGIN_URL contains an id parameter. So, as there is already a parameter in the URL any further params have to be appended using & instead of ? (see code change below).
2. With felogin 1.3.0 the redirect_url parameter is not correctly interpreted. I am quite sure that this is a bug, but did not investigate this route. The better solution is to use the referrer parameter and in the felogin plugin settings set the redirect mode to \defined by Referrer. This also makes it possible to define the priority of different redirects. Together with the change in 1. this results in the following code change:
$url = LOGIN_URL.(strpos(LOGIN_URL, ‘?’)===false?’?’:’&’).\referer=.$param[\currentUrl\];
3. VERY IMPORTANT: The current version 1.3.0 of felogin contains a bug which impedes the correct function of the referer param (see http://bugs.typo3.org/view.php?id=12990). To make it work you have to apply the latest patch in that bug report. It has been committed to trunk on 05/31/2010 so it will probably be part of the core in the next T3 versions.
Thanks again for your nice work!
Cheers, Jörg.
Hmmm. WordPress heavily destroyed my code change line. I hope you can figure it out as I dont know how to enter it so that is not corrupted. With a bit of PHP knowledge it should be obvious. Maybe Richard can correct it.
Cheers, Jörg.
Well, unfortunatelly this was not all.
The param “referer” is unfortunatelly also used when calling the login page from some other page in the website. In this case my posted solution will redirect after login back to the calling page, which is not at all desireable.
The final solution reverts back to redirect_url and I will send it in a separate posting, so Richard can delete all this intermediate stuff if he wishes. Here we go…
dann wird nach dem Login fälschlicherweise dorthin zurück gekehrt. Also zurück zu redirect_url. Wie bereits in meinem ersten Posting vermutet, gibt es hier in felogin 1.3.0 einen Bug. Dieser ist in TYPO3 4.4.0 behoben (die Sysext trägt dort aber komischerweise immer noch die Versionsnummer 1.3.0). Um ihn in älteren T3-Versionen zu beheben:
In
/typo3/sysext/felogin/pi1/class.tx_felogin_pi1.php
die Zeile
if (!$gpRedirectUrl && $this->redirectUrl && $this->logintype === ‘login’) {
ändern in
if (!$gpRedirectUrl && $this->redirectUrl) {
(also die dritte Condition löschen).
Oh damn - I am really flooding this thread - everything in German in the last posting was not meant to be posted. Please ignore / delete…
Very nice, Richard!
I just implemented your solution in a TYPO3 4.3.2 website using the felogin sysext for logins and I had to change some details to get it working:
1. As I don’t use RealURL or static URLs in this project, my LOGIN_URL contains an id parameter. So, as there is already a parameter in the URL any further params have to be appended using & instead of ?.
This results in the following code change:
$url = LOGIN_URL.(strpos(LOGIN_URL, ‘?’)===false?’?’:’&’).”redirect_url=”.$param[“currentUrl”];
Unfortunatelly this blog software heavily degrades the above code line. I hope you can figure it out as I dont know how to enter it so that is not corrupted. With a bit of PHP knowledge it should be obvious. Maybe Richard can correct it.
2. With felogin 1.3.0 in TYPO3 4.3.2 the redirect_url parameter is not correctly interpreted. This is a bug and it is corrected in TYPO3 4.4.0 (strange enough the sysext still has version 1.3.0 there!). To fix this problem in older versions of T3 do the following:
In…
/typo3/sysext/felogin/pi1/class.tx_felogin_pi1.php
change this line…
if (!$gpRedirectUrl && $this->redirectUrl && $this->logintype === ‘login’) {
to this…
if (!$gpRedirectUrl && $this->redirectUrl) {
(delete the third condition entirely).
3. With felogin you have to set the redirect mode in the plugin settings to ‘defined by GET/POST-Vars’ to activate the interpretation of the redirect_url GET parameter. This also makes it possible to define the priority of different redirects.
Thanks again for your nice work!
Cheers, Jörg.