Bug #19912

The Bug 0010205 "DB session records are only created when users authenticate " is not solved in Typo 4.2.5 and 4.1.9

Added by Maik Matthias over 10 years ago. Updated 12 months ago.

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

0%

TYPO3 Version:
4.2
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

After login of a FE-user you immediately get logged out when clicking any link.

You can reproduce the bug on IE7 (on Windows Vista or Win XP). FF seems to work fine. The problem exists on Typo 4.2.5, 4.1.9 and the older versions 4.2.4 and 4.1.8.

I made a downgrade to the affected sites to Typo 4.2.3 and 4.1.7 and all works good as before.
(issue imported from #M10261)


Related issues

Related to TYPO3 Core - Bug #19879: after upgrade from 4.1.7 to 4.1.8 feusers and beusers have to clear there cookie cache before they can login Closed 2009-01-21
Related to TYPO3 Core - Bug #19908: session fixation fix avoid BE login Closed 2009-01-25
Related to TYPO3 Core - Bug #19916: Session handling - cannot login to >1 TYPO3 installation under one domain Closed 2009-01-26

History

#1 Updated by Ingmar Schlecht over 10 years ago

Hi Maik,

could you please try again after you manually deleted all cokies from IE7 (with the versions you experienced the bug with).

cheers
Ingmar

#2 Updated by Maik Matthias over 10 years ago

Hello Ingmar,

i deleted the cookies severeal times. Also I testet it on different maschines, some never opened the Website before.

First idea was to empty all caches and to delete all files in typo3temp as well: no effect.

The FE-session is stored only when logged in BE and still exists after logging out of BE. Logging out from FE is then impossible until Browser is closed. The reason is possibly that you can´t store any DB session data outside the BE.

#3 Updated by Michael Klapper over 10 years ago

Hi Maik,

i can not aggree that issue.

Regards,
Mick

Tested on ========
OS: Windows XP SP3
Browser IE 7.0.57.30.13, Firefox 3.0.5

#4 Updated by Manfred Mueller-Spaeth over 10 years ago

Same problem with me according to Maik's description. I don't know the reason yet, but I know I may not use the version 4.2.4 or 4.2.5 because FE users are always logged out with the next page request (I described the behaviour in #19867 as well earlier).

It's reproducable: if you truncate the fe_session table and login as fe_user - the next request on a secured page will produce an error. You may repeat this, it's the same result.

Emptying caches, clearing cookies and so on will show no effect. And it's not depending on the browser - e.g normally I use FireFox.

It's really a problem, because I may not roll out the version 4.2.5 ...

#5 Updated by Christian Karsten over 10 years ago

Same problem here, but only when using a redirect to a subdomain:

- 1st request to <domain>.de is a redirect (via domain record in TYPO3) to www.&lt;domain&gt;.de, cookie A is set, no session data in DB

- 2nd request goes to www.&lt;domain&gt;.de, Browser sends cookie A, TYPO3 sets cookie B, still no session data in DB

- 3rd requests to www.&lt;domain&gt;.de with login: IE7 sends cookie A, FF sends cookie B, TYPO3 sets cookie C and creates session in DB

- 4th request to www.&lt;domain&gt;.de: IE7 sends cookie A, FF sends cookie C. Only the session for cookie C is logged in...

temp. workaround: redirect in apache.conf or .htaccess instead of TYPO3

Maybe it would be a good idea to set the sessioncookie only when a session is really created in db (does not solve this issue in all cases)?

May be related to 0010257 and 0010266

EDIT: Correction: IE7 sends back BOTH Cookies A (which has been set for <domain>.de) and B (www.&lt;domain&gt;.de), but only the 1st (A) is seen in $_COOKIE["fe_typo_user"]. FF uses only the one cookie that was set for the exact name.

#6 Updated by Maik Matthias over 10 years ago

I made a lot of testing until today. Maybe I can describe the bug better now:

The bug only occurs with IE (version 6 or 7) and the Typo-Versions 4.1.8, 4.1.9, 4.2.4 amd 4.2.5.

I tested it on three different servers with different Typo-Installations:
- Apache 2.2.3 / PHP 5.2.6
- Apache 2.2.3 / PHP 5.1.2
- Apache 1.3.39 / PHP 5.2.8

=> same result everywhere.

The behaviour of the Login depend on what (sub-)domain you are enter a Website. You should not change the domain while surfing the site.

Try this:

1) Open a new IE-window and enter the typo-Site with: http://domain.tld
2) Make a FE-Login to the site and click some links. Then logout. It´s all ok.
3) Go to the address bar of the IE and type: http://www.domain.tld
4) Make a FE-Login and try to click any link then: You will immediately get logged out.

Trying to make a (double) BE-Login in the same manner raises a "Login-error or session timed-out"-Error.

Making a Domain-Record to forward domain.tld to www.domain.tld didn´t solve the problem (and this could not be a long term solution anyway).

I guess, there is a bug in handling the domain in the session- and/or cookie-data.

Hope someone can help - or recognize my fault.

#7 Updated by Marcus Krause over 10 years ago

Dear Maik,

I would describe your "problem" as "works as expected".
example.org and www.example.org are totally different.

What's your problem? If the content is the same for both domains, just make an APACHE redirect from example.org to www.example.org. I guess this would solve it.

Another solution would be an adjustment to $TYPO3_CONF_VARS['SYS']['cookieDomain'].

#8 Updated by Maik Matthias over 10 years ago

Hello Marcus,

thanks for your advice. I agree with you, www.example.de and example.de are different domains. But: In my opinion the cookie and session data therefore have to be treated fully independend. Now a login to www.example.de blocks other logins to example.de and vice versa. I can´t see a feature in this behaviour, which is new since Typo 4.2.4 / 4.1.8.

Good news: Your workaround setting the cookieDomain-variable seems to work in some cases. But not in all.

I think this problem is still relevant. Is there anybody else who still suffers this problem?

PS: I know that the title of this bug-report is not appropriate anymore, cause it´s about more generous login problems. The relationships added by Marcus may be helpful.

#9 Updated by Helmut Hummel over 10 years ago

Hi Maik,
in exactly what cases setting cookieDomain does not help?

#10 Updated by Maik Matthias over 10 years ago

Hi Helmut,

it seems, that the extension EfA Font Size ( efafontsize ) - see bugreport 0010216 - additionally made the trouble.

I disabled the extension, cleared all cookies and the FE-login works. Unfortunately your "fixed" cookies.js don´t work for me, it just generates javascript errors. Therefore I have to leave the fontsizer extension disabled.

Thanks for your help, I didn´t think about this extension (why does a fontsizer need cookies?).

#11 Updated by Helmut Hummel over 10 years ago

Hi Maik, good to hear, that this issue is also caused by this mad piece of JavaScript. I now uploded a new version of the cookie.js, which does not contain any debugging code any more (which caused the JavaScript errors because it used a logging function, which only works with Firebug enabled). Additionally it now only touches the "efaSize" cookie (thx to Albert van der Veen for this suggestion).

FYI: The fontsizer uses the cookie for storing the size of the font, so that you do not need to resize it on every page change...

I will mark this issue as resolved ...

#12 Updated by Benni Mack 12 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF