TYPO3 Core

Same problem after upgrading a site from 4.5 to 6.2.

Stanislas Rolland wrote:

Same problem after upgrading a site from 4.5 to 6.2.

In my case, after unsetting [SYS][cookieDomain], frontend login works again. So maybe there is a problem there.

Stanislas Rolland wrote:

In my case, after unsetting [SYS][cookieDomain], frontend login works again. So maybe there is a problem there.

Well, a cookie is set, but as soon as the user navigates, he is not logged in anymore.

Stanislas Rolland wrote:

Stanislas Rolland wrote:

In my case, after unsetting [SYS][cookieDomain], frontend login works again. So maybe there is a problem there.

Well, a cookie is set, but as soon as the user navigates, he is not logged in anymore.

This is also the case here. The [SYS][cookieDomain] wasn't set before the update, now it's set but not making any difference.

Have exactly the same problem!
After upgrading from TYPO3 6.1.7 to 6.2.0 felogin don't works correctly.
1.) Starting felogin for sign in, a cookie fe_typo_user is created
2.) After login the correct status "user logged in" is shown, a row in fe_session and fe_session_data is created BUT the cookie fe_typo_user is DELETED ... therefore the user loose the "log in", that means any following click which force a GET/POST shows the status user logged out.

Sievert Peter wrote:

Have exactly the same problem!
After upgrading from TYPO3 6.1.7 to 6.2.0 felogin don't works correctly.
1.) Starting felogin for sign in, a cookie fe_typo_user is created
2.) After login the correct status "user logged in" is shown, a row in fe_session and fe_session_data is created BUT the cookie fe_typo_user is DELETED ... therefore the user loose the "log in", that means any following click which force a GET/POST shows the status user logged out.

Thanks for the better description, this is the same I have found wrong.

I added some relations to patches that went into 6.2 which might be related.

I think there is more to this misbehaviour. Although the frontend user is shown as logged in, if he is part of a user group that should be given access to some page, such page does not show up in the menu.

@Stanislas: Can that be a caching issue? Even client side caching?

Markus Klein wrote:

@Stanislas: Can that be a caching issue? Even client side caching?

I doubt it. I have been clearing all caches on both sides.

I feared as much. Need to do an extensive debugging session.

Actually, after reading your findings, I think #55845 is the least responsible. Maybe none of the linked issues is responsible.

The cookieDomain stuff is only used in the removeCookie() and setSessionCookie() methods. i.e. if you change the domain, different cookies are set/removed.
So I'll take this as a starting point to find out, where the cookie/session is removed too often.

1. feLogin works, but the cookie is unset and therefore for any subsequent click the user is not logged in anymore
2. feLogin works, but the logged in state is not reflected in menus that should show menu items for logged in users.

Number 2 is working for me.

I couldn't reproduce number 1 either.

What are the settings of your login-form?

Markus Klein wrote:

A short summary for the current problems:

1. feLogin works, but the cookie is unset and therefore for any subsequent click the user is not logged in anymore
2. feLogin works, but the logged in state is not reflected in menus that should show menu items for logged in users.

I found the second problem to be unrelated to this issue. Apparently, felogin does not respect any storagePid setting be it in TypoScript, on the flexform or both. I will investigate this further, and submit a separate issue.

However, the initial issue remains.

For me it respects the storage pid. both, via TS and flexform.

Can't reproduce number 1 though

Markus Klein wrote:

For me it respects the storage pid. both, via TS and flexform.

You're right. I had [FE][checkFeUserPid] unset.

Not a solution, but a temporary workaround: setting dontSetCookie to FALSE in FrontendUserAuthentication.

"TYPO3 now only sets a frontend user cookie (fe_session) if there is session data or the user is logged in. This minimizes traffic, allows better optimization of reverse proxies (i.e. varnish). It also makes the setting “dontSetCookie” obsolete."

Sorry, I don't understand your workaround!?

Sievert Peter wrote:

After updating to 6.2.1 a temporary solution for thiS problem is to set:

public $forceSetCookie = TRUE;

(Line 365 in ../typo3/sysext/core/classes/authentication/AbstractUserAuthentication.php)

After changing the setting, the fe_user_cookie is created corect with the user login!

This solution is working for me!

@Robbert: Sure this works, but you now have a cookie whenever a user comes to your site. Not only when the user tries to login. The core strives to set a cookie only when needed, so this is a workaround that might not fit everybody's needs.

@all review: Can you please tell my your felogin settings, redirect methods, etc so I can reproduce this?

@Markus:

1. Click on the "password forgotton" link (a cookie is now set)
2. Go back to login form (cookie is still there)
3. Login

Login is successful but cookie is now gone and after click your not logged-in anymore.

I can confirm the problem and the solution (forceSetCookie) when using TYPO3 6.1.8 and Microsoft Internet Explorer 11 on Windows 7 64 bits. I had a list of files to be downloaded, for authenticated members, secured with naw_securedl, but when using IE the frontend user was not properly reinstantiated in \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::initFEuser and this led to an error to download the file (no user...).

No problem found with other browsers.

@Xavier: This is really strange since the changes referenced here did not go into 6.1 branch.

@frans: Thx for the instructions. I can reproduce this now and will debug tonight.

Works fine :-)
Thanks a lot!!

Fix will be reverted with #59614 as a better solution #58713 was merged.

Unfortunately the solution is still not available in latest TYPO3 6.2.7 release.
Previous releases also didn't have this fix with them. After manually adjusting the fix everything works fine.

As written above, the patch for this very ticket has been reverted, but a solution has been merged with #58713.

The solution doesn't work for my case. When I'm logged in and navigate through my website I get reverted to the login page en my fe_login cookie is destroyed.

Robert, please open a new ticket, add your configuration of

[FE][checkFeUserPid]
[FE][lockIP]
[FE][loginSecurityLevel]
[FE][lifetime]
[FE][sessionDataLifetime]
[FE][permalogin]

to the description, add me as watcher and add a relation to this issue after creating the ticket.

Thanks a lot.