Bug #57751

Felogin session not set

Added by Robbert V over 7 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Must have
Assignee:
Category:
felogin
Target version:
-
Start date:
2014-04-08
Due date:
% Done:

100%

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

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 TYPO3 Core - Bug #53598: Select/Delete fe_sessions twice per requestClosedAlexander Opitz2013-11-13

Actions
Related to TYPO3 Core - Task #55549: Only set FE user cookie if session data or user logged inClosedBenni Mack2014-02-01

Actions
Related to TYPO3 Core - Bug #58957: Frontend User Session by POST ['recs']['ts']Rejected2014-05-20

Actions
Related to TYPO3 Core - Bug #58713: Failed feuser login removes the existing session dataClosed2014-05-12

Actions
Related to TYPO3 Core - Bug #59614: The property newSessionID is used in a wrong context in AbstractUserAuthenticationClosed2014-06-16

Actions
Related to TYPO3 Core - Bug #63597: Felogin session cookie is destroyed when navigating after loginClosed2014-12-05

Actions
Is duplicate of TYPO3 Core - Bug #57746: FE-User Session is deleted on login attempt / Login fails if Session is not emptyClosed2014-04-08

Actions
Is duplicate of TYPO3 Core - Bug #57724: Not logged in after "Forgot your password?" procedure with redirectModeClosed2014-04-07

Actions
#1

Updated by Stanislas Rolland over 7 years ago

Same problem after upgrading a site from 4.5 to 6.2.

#2

Updated by Stanislas Rolland over 7 years 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 7 years 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 7 years 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 7 years 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 7 years 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 7 years ago

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

#8

Updated by Stanislas Rolland over 7 years 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 7 years ago

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

#10

Updated by Stanislas Rolland over 7 years 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 7 years ago

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

#12

Updated by Sievert Peter over 7 years ago

  • Assignee 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 7 years 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 7 years 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 7 years ago

Number 2 is working for me.

#16

Updated by Markus Klein over 7 years ago

I couldn't reproduce number 1 either.

What are the settings of your login-form?

#17

Updated by Stanislas Rolland over 7 years 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 7 years 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 7 years ago

  • Assignee deleted (Markus Klein)
#20

Updated by Stanislas Rolland over 7 years 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 7 years ago

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

#22

Updated by Sievert Peter over 7 years 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 7 years ago

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

#26

Updated by Frans Saris over 7 years 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 7 years 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 7 years ago

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

#29

Updated by Markus Klein over 7 years ago

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

#30

Updated by Gerrit Code Review over 7 years 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 7 years ago

  • Status changed from Under Review to Closed
#32

Updated by Markus Klein over 7 years ago

  • Status changed from Closed to Under Review
#33

Updated by Markus Klein over 7 years ago

  • Status changed from Under Review to Closed

Closing this in favor of #57751.

#34

Updated by Markus Klein over 7 years 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 7 years ago

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

Updated by Sievert Peter over 7 years ago

Works fine :-)
Thanks a lot!!

#37

Updated by Markus Klein over 7 years ago

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

#38

Updated by Robbert V almost 7 years 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 almost 7 years 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 almost 7 years 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 almost 7 years 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.

#42

Updated by Benni Mack almost 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF