Project

General

Profile

Actions

Bug #61287

closed

Immediately logged out from FE after felogin

Added by Claudio Strizzolo over 9 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2014-09-01
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

I am upgrading a working site from Typo3 4.5 to 6.2.4. Almost everything seems to work fine except for some pages that should be accessible only by FE users through a felogin form, which worked correctly with 4.5.

The felogin form itself seems to work correctly: if the user supplies the right password, he logs in and can see the protected contents on that page. But if he changes to a different page he loses his "logged-in" status. So if he tries to view another page reserved to FE users he cannot do it, as if he never logged in. Even if he tries to load again the first page (that one that was shown after the initial login), he is not able to do it: the user is reported as if I never logged in and the login form is shown again.

It looks like the user gets logged out immediately.

I tried by playing with the permalogin switch without success.

I am using the ig_ldap_sso_auth extension to authenticate users against a LDAP database. On Typo3 4.5 I used the extension eu_ldap. However, I do not think that the autentication step is reponsible because the user can actually log in through the FE form (BTW, BE users can log in too using the same LDAP database).
No problems at all with the BE, instead.

I looked at the cookies at different steps:

Before login: no cookies

After login and viewing the first protected page, which is the same page as the login page, no redirect to a different page:
cookie: fe_typo_user
value: e52b5...

Jump to another page (not protected):
same cookie

Jump back to the first protected page:
same cookie

Although the cookie is still set, the login form is displayed again. The login form should be displayed only for not logged FE users, instead, so it looks like I am not logged on any more.

Some settings that might be involved follow:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['cookieDomain']

I tried with either an empty string and the address of my site. In both cases I can login to the BE but in the FE I get the wrong behaviour I described.

$GLOBALS['TYPO3_CONF_VARS']['SYS']['cookieSecure']

0

$GLOBALS['TYPO3_CONF_VARS']['FE']['cookieDomain']

Empty string, then the value of $GLOBALS['TYPO3_CONF_VARS']['SYS']['cookieDomain'] should be used.

$GLOBALS['TYPO3_CONF_VARS']['FE']['lifetime']

3600


Files

snap1.png (51.6 KB) snap1.png Claudio Strizzolo, 2014-09-01 15:32
snap2.png (30.2 KB) snap2.png Claudio Strizzolo, 2014-09-01 15:32
snap3.png (62.5 KB) snap3.png Claudio Strizzolo, 2014-09-02 08:27
snap4.png (15.4 KB) snap4.png Claudio Strizzolo, 2014-09-02 08:50

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #60264: felogin permalogin not working with typo3 6.2.x -> cookie expires with sessionClosed2014-07-11

Actions
Actions #1

Updated by Markus Klein over 9 years ago

There has been a bug with permalogin that will be fixed with 6.2.5. (#60264)
Maybe you can test, if this also resolves your problem?
http://review.typo3.org/31754

Actions #2

Updated by Claudio Strizzolo over 9 years ago

Hi Markus,
unfortunately that patch does not resolve my problem.

Actions #3

Updated by Markus Klein over 9 years ago

Hi Claudio,

can you please post a complete description of your setup?

  • Page structure incl. which page is accessible with which condition
  • Login form settings

Updated by Claudio Strizzolo over 9 years ago

See snap1.png.
Basically the page "Gestione archivi" and the pages under it should be readable only by logged in users. A reminder should be displayed to any users (either logged in or not), if they try to view any of those pages, saying that the content is readable only if they log in plus some more information, therefore the protection is not at the page level, but at the page content elements level.
In the snapshot you can see the content elements of "Gestione archivi", the other pages are similar:

  • a block that must be always displayed ("Questa pagina consente..."): no filter on it.
  • the Login form, with protection "Hide at login".
  • "Sito per il pubblico" and "Sito per gli utenti INFN" with protection "Show at any login".

Now, when I load the page "Gestione archivi" the first time, I get the Login form. I fill the form and log in correctly. Some TS code makes me able to see if I am logged in when staying on a page or not. The page is reloaded, the TS code says I am logged in, the login form disappears ad the two blocks "Sito per il pubblico" and "Sito per gli utenti INFN" get displayed correctly. Correct up to now.
After that, if I try to access either one of the protected subpages of "Gestione archivi", or an unprotected page (like "Wireless"), the TS code says I am not logged in: accordingly, I cannot see the protected contents. If I return back to "Gestione archivi", the Login form is displayed again, as if I never succeeded in logging in.

The login plugin settings are in snapshot snap2.png.

TS felogin settings:

plugin.tx_felogin_pi1 { # General Record Storage Page ID here
storagePid = 294

showPermaLogin = 1
templateFile=fileadmin/template/layout09/felogin/felogin_interno.html
}
Actions #5

Updated by Markus Klein over 9 years ago

  • Category deleted (felogin)
  • Status changed from New to Needs Feedback

I setup a test site with your setup and couldn't find any problems.

Maybe some extension is making troubles? Which are installed?

Actions #6

Updated by Claudio Strizzolo over 9 years ago

A lot of extensions are installed: the site is rather complex and offers a lot of services.
You may see the list of extensions in the attached image.
LDAP / SSO Authentication (ig_ldap_sso_auth) is not in the image but is installed too.

Actions #7

Updated by Claudio Strizzolo over 9 years ago

I tried to remove most of the extensions. I let only the ones that should be strictly needed to make the basic site work (see attached image).
Unfortunately the problem is still there.

Actions #8

Updated by Markus Klein over 9 years ago

I'm almost sure that realurl is not the culprit. I don't know the other extensions though.
You mentioned ig_ldap_sso_auth, which should not be responsible, but maybe it still does something strange.

I'm at a point, where I can only recommend you to debug this instance. Start with typo3/sysext/core/Classes/Authentication/AbstractUserAuthentication.php

Actions #9

Updated by Claudio Strizzolo over 9 years ago

Hi Markus,
I'm still working on the problem.
I tried also by changing the PHP version on the server (5.4 vs. 5.5) but the problem is still there.
Would you be so kind to post the Install Tool settings for both the FE and SYS you used in your working testbed? Maybe I have a wrong setting somewhere. I guess the FE and SYS sections of typo3conf/LocalConfiguration.php should be enough.
Thanks in advance.

Actions #10

Updated by Markus Klein over 9 years ago

Sure, here we go:

'FE' => array(
    'debug' => '0',
    'lifetime' => '',
    'loginSecurityLevel' => 'rsa',
),
'SYS' => array(
    'UTF8filesystem' => '1',
    'caching' => array(
        'cacheConfigurations' => array(
            'extbase_object' => array(
                'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\ApcBackend',
                'frontend' => 'TYPO3\\CMS\\Core\\Cache\\Frontend\\VariableFrontend',
                'groups' => array(
                    'system',
                ),
                'options' => array(
                    'defaultLifetime' => 0,
                ),
            ),
        ),
    ),
    'clearCacheSystem' => '0',
    'compat_version' => '6.2',
    'devIPmask' => '*',
    'displayErrors' => '1',
    'enableDeprecationLog' => 'file',
    'encryptionKey' => '....',
    'exceptionalErrors' => '28674',
    'isInitialInstallationInProgress' => FALSE,
    'lockingMode' => 'semaphore',
    'sitename' => 'T3 Master',
    'sqlDebug' => '1',
    'systemLocale' => 'en_GB.utf8',
    'systemLog' => 'error_log',
    'systemLogLevel' => '0',
    't3lib_cs_convMethod' => 'mbstring',
    't3lib_cs_utils' => 'mbstring',
    'trustedHostsPattern' => 'kleindev',
),
Actions #11

Updated by Claudio Strizzolo over 9 years ago

I have discovered that the problem is somehow related to the ig_ldap_sso_auth extension, although it pops up only after the login step. If I disable that extension and authenticate locally, the problem disappears.
I do not know yet if it is just a misconfiguration or a bug in that extension, in any case this bug report related to felogin can be closed.
Thanks for your help.

Actions #12

Updated by Markus Klein over 9 years ago

  • Status changed from Needs Feedback to Closed
Actions

Also available in: Atom PDF