Bug #57751

Felogin session not set

Added by Robbert V over 1 year ago. Updated 5 months ago.

Status:Resolved Start date:2014-04-08
Priority:Must have Due date:
Assigned To:Markus Klein % Done:

100%

Category:felogin Spent time: -
Target version:-
TYPO3 Version:6.2 Is Regression:No
PHP Version:5.3 Sprint Focus:
Complexity:

Description

After upgrading my TYPO3 6.1.7 installation to 6.2.0 the felogin form is working properly anymore. I have been wondering around on the internet and haven't found someone with the same problem.
As far as i can tell at the moment the felogin extension doesn't set the cookie for fe_typo_user. So if I log in I get redirected to the correct page, when I want to navigate I end up on de login screen.

There are no errors in console, reports, logs or whatever. Cookie domain is set correctly, also BE login and Install Tool are working without any prob


Related issues

related to Core - Bug #53598: Select/Delete fe_sessions twice per request Resolved 2013-11-13
related to Core - Task #55549: Only set FE user cookie if session data or user logged in Resolved 2014-02-01
related to LDAP / SSO Authentication - Bug #64018: Lost logged in status when switching page - ig_ldap_sso Closed 2014-12-22
related to Core - Bug #63597: Felogin session cookie is destroyed when navigating after... New 2014-12-05
related to Core - Bug #59614: The property newSessionID is used in a wrong context in A... Resolved 2014-06-16
related to Core - Bug #58713: Failed feuser login removes the existing session data Resolved 2014-05-12
related to Core - Bug #58957: Frontend User Session by POST ['recs']['ts'] Needs Feedback 2014-05-20
duplicates Core - Bug #57746: FE-User Session is deleted on login attempt / Login fails... Closed 2014-04-08
duplicates Core - Bug #57724: Not logged in after "Forgot your password?" procedure wit... Closed 2014-04-07

Associated revisions

Revision 76741dff
Added by Markus Klein over 1 year ago

[BUGFIX] Session cookie is not recreated on login

In case login data is submitted and there is an existing cookie/session
the current session is discarded and the current cookie is unset.
Subsequently the login data is processed and login succeeds and a
new session is established, but the new cookie is not set.

Fix this be correctly remembering that we need to set a new cookie,
after we disposed the current one.

Resolves: #57751
Releases: 6.2
Change-Id: I2e4b4a381b4e557aeb95c4186c6e5365dbea442a
Reviewed-on: https://review.typo3.org/29626
Reviewed-by: Fabien Udriot
Reviewed-by: Stefan Neufeind
Reviewed-by: Robbert V
Tested-by: Robbert V
Reviewed-by: Frans Saris
Tested-by: Frans Saris
Reviewed-by: Oliver Hader
Tested-by: Oliver Hader

History

#1 Updated by Stanislas Rolland over 1 year ago

Same problem after upgrading a site from 4.5 to 6.2.

#2 Updated by Stanislas Rolland over 1 year ago

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.

#3 Updated by Stanislas Rolland over 1 year ago

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.

#4 Updated by Robbert V over 1 year ago

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.

#5 Updated by Sievert Peter over 1 year ago

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.

#6 Updated by Robbert V over 1 year ago

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.

#7 Updated by Markus Klein over 1 year ago

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

#8 Updated by Stanislas Rolland over 1 year ago

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.

#9 Updated by Markus Klein over 1 year ago

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

#10 Updated by Stanislas Rolland over 1 year ago

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.

#11 Updated by Markus Klein over 1 year ago

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

#12 Updated by Sievert Peter over 1 year ago

  • Assigned To set to Markus Klein

Hi Markus,

i have updated my actual 6.2 from referenced "Bug #55845: Wrong check removes FE cookie" with file FrontendUserAuthentication.php from 2014-04-12 08:15

Cleared all caches (remove typo3temp an recreated it, BE and FE caches)

unfortunately the same as before, when logging in, the cookie fe_user_cookie is deleted!

My felogin settings:
[FE][checkFeUserPid] = 1
[FE][lockIP] = 0
[FE][loginSecurityLevel] = rsa
[FE][lifetime] = ""
[FE][sessionDataLifetime] = 86400
[FE][permalogin] = -1
Working with a subdomain for developement dev.xxxxx

May be something i found out helps to reproduce this problem:
Every time i change
[FE][cookieDomain] =
the login works fine until i close the browser (firefox) and start a new browser session!
For example:
1.Changing [FE][cookieDomain] from Blank to def.mydomain.de
2.Clearing all Caches
3.Login works fine (this means fe_user_cookie will not be removed when logging in)!
4.Closing the Browser and start a new session
5.Loging fails because fe_user_cookie will be removed when loging in!
6.Changing [FE][cookieDomain] from def.mydomain.de to Blank
7.Clearing all Caches
8.Login works fine (this means fe_user_cookie will not be removed when logging in)!
... and so on ... (same effect when using/changing setting [SYS][cookieDomain])

Thanks in advance and best regards!

Peter

#13 Updated by Markus Klein over 1 year ago

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.

#14 Updated by Markus Klein over 1 year ago

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.

#15 Updated by Markus Klein over 1 year ago

Number 2 is working for me.

#16 Updated by Markus Klein over 1 year ago

I couldn't reproduce number 1 either.

What are the settings of your login-form?

#17 Updated by Stanislas Rolland over 1 year ago

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.

#18 Updated by Markus Klein over 1 year ago

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

Can't reproduce number 1 though

#19 Updated by Markus Klein over 1 year ago

  • Assigned To deleted (Markus Klein)

#20 Updated by Stanislas Rolland over 1 year ago

Markus Klein wrote:

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

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

#21 Updated by Stanislas Rolland over 1 year ago

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

#22 Updated by Sievert Peter over 1 year ago

"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!?

#23 Updated by Sievert Peter over 1 year ago

  • Assigned To set to Markus Klein

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!

#24 Updated by Robbert V over 1 year ago

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!

#25 Updated by Markus Klein over 1 year ago

@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: Can you please tell my your felogin settings, redirect methods, etc so I can reproduce this?

#26 Updated by Frans Saris over 1 year ago

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

#27 Updated by Xavier Perseguers over 1 year ago

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.

#28 Updated by Markus Klein over 1 year ago

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

#29 Updated by Markus Klein over 1 year ago

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

#30 Updated by Gerrit Code Review over 1 year ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/29626

#31 Updated by Markus Klein over 1 year ago

  • Status changed from Under Review to Closed

#32 Updated by Markus Klein over 1 year ago

  • Status changed from Closed to Under Review

#33 Updated by Markus Klein over 1 year ago

  • Status changed from Under Review to Closed

Closing this in favor of #57751.

#34 Updated by Markus Klein over 1 year ago

  • Status changed from Closed to Under Review

Redmine does strange things. If I close other tickets which are somehow related as duplicate to this one, this ticket is always closed too.

#35 Updated by Markus Klein over 1 year ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#36 Updated by Sievert Peter over 1 year ago

Works fine :-)
Thanks a lot!!

#37 Updated by Markus Klein about 1 year ago

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

#38 Updated by Robbert V 8 months ago

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.

#39 Updated by Markus Klein 8 months ago

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

#40 Updated by Robbert V 8 months ago

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.

#41 Updated by Markus Klein 8 months ago

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.

Also available in: Atom PDF