TYPO3 Core

TYPO3 4.3.1
Have a similar problem logging in at subdomains.
If we take mydomain.dk as example - it seems the problem is that the domain of fe_typo_user is set to .dk and not mydomain.dk
This happens for IE and not Firefox.
So if you have been on the main site (without www), then a fe_typo_user cookie is set to .dk and then it obviously gives some problems when trying to login at a subdomain...

I have also been able to reproduce the cookie problem on an installation which is not ours.
With IE8, try to go to busynoggin.com and then see your cookies. fe_typo_user will be registered as .com and not busynoggin.com.

Setting cookieDomain in the install tool doesn't change anything.
I have also tried to disabling extensions too see if the problem was an extension interferring with the cookies. Seems to be a 4.3.x problem with IE8 (... IE x??)

Problem also described in this post:
http://lists.typo3.org/pipermail/typo3-english/2010-January/066468.html

As a "workaround", set this:

$TYPO3_CONF_VARS['SYS']['cookieDomain'] = '/.*/';

and TYPO3 will always return the "domain=" specific for the domain the user has visited. This should solve this specific trouble.

Well I guess this isn't a workaround in my case.
We have two TYPO3 installations.
A main site mydomain.dk
This one has a link to the secondary site - support.mydomain.dk

So if we go from mydomain.dk to support.mydomain.dk - frontend login is not possible. Our temporary fix, is to have another temporary domain for the support site - like support.anotherdomain.dk instead of support.mydomain.dk.

But that is of course not a acceptable solution in the long run.

This problem is related to

a) the "fe-session fixation" fix which changes the session ID whenever there is no session data stored yet. This was introduced in 4.2.4 (and also 4.3.0) so the problem might not appear on previous TYPO3 versions.

b) an IE8 "bug" (or feature?) which is reproduceable.

How it works:

1) The trouble begins if you visit the site without "www.". TYPO3 will generate a fe_typo3_user=AAA cookie and send it to the IE8 (Set-Cookie).

2) Then you switch to the "www." version (or the "support." variant). Because the user is not logged in yet, there is no session data, so TYPO3 will generate a new fe_typo3_user=BBB cookie for that request also.

Now the IE8 bug comes in. On every further request, it will send both cookies back to the server:

Cookie: fe_typo_user=AAA; fe_typo_user=BBB

PHP will use the first one: $_COOKIE['fe_typo_user'] = "AAA".

3) user then "loggs in". TYPO3 will store the information in the "BBB" session. For "this hit" the user is logged in.

4) On next request (user clicks somewhere else), PHP again passes the "AAA" cookie to TYPO3 (session where the user hasn't logged in) so TYPO3 thinks it is not logged in (and will also generate a new session id).

This seems only to happen for cookies set for a host that is shorter (e.g. "domain.XXX") and later you switch to a more specific host (e.g. "www.domain.XXX").

The IE8 bug doesn't depend if you send or not a "domain=" specifier with your cookie, meaning that the TYPO3 setting "cookieDomain" doesn't make the trouble disappear.

A potential solution would be to have TYPO3 analyse the $_SERVER['HTTP_COOKIE'] variable instead of relying on $_COOKIE only.

You might want to check if this is the problem by temporarily disabling the session fixation fix, meaning reverting this change:

http://forge.typo3.org/repositories/diff/typo3v4-core/branches/TYPO3_4-2/t3lib/class.t3lib_userauth.php?rev=4784

Claus, Stig, and others who have had this problem. Could you please test the attached patch if it fixes the problem? It is a 4.2 patch but should also apply to 4.3.

Thanks!

I changed:
if (!$id || !$this->isExistingSessionRecord($id)) {
to:
if (!$id) {

Still get following cookie information (all browser cache cleared before):
NAME fe_typo_user
VALUE a26f52bd47d726773d1134668861cea0
DOMAIN .dk
PATH /
EXPIRES At the end of the Session

I will try the patch next.

Got this error when trying to implement patch:

patching file t3lib/class.t3lib_userauth.php
Hunk #1 FAILED at 212.
Hunk #2 succeeded at 806 (offset 480 lines).
1 out of 2 hunks FAILED -- saving rejects to file t3lib/class.t3lib_userauth.php.rej

Then tried to implement the rejects manually.

Still:
NAME fe_typo_user
VALUE c399b8160e0e069eff709dfc8e92fd6f
DOMAIN .dk
PATH /
EXPIRES At the end of the Session

Another observation. This will also happen when I go to www.mydomain.dk.

Also - I have not currently any tools to test i thoroughly with IE7...
Maybe it's a IE - 4.3 problem?

Stig, the patch won't change what IE8 "developer tool" displays, because the cookies passed are the same as before. It will however change TYPO3s working with the cookies IE8 sends, meaning that login should now work cross subdomains. Can you confirm this?

Thanks for clarifying.
After the patch, the problem I described (*) is now solved.

• http://bugs.typo3.org/view.php?id=13470#c34902

Tested 13470_v2-trunk.diff with TYPO3 4.3.2.
No errors when patching. Bug seems fixed. All seems fine.

Stig, could you please join the typo3 core list and give a "+1 on testing" from you to the issue there (search for RFC #22084). See http://typo3.org/teams/core/core-mailinglist-rules/

Thanks!

Comited to:

- trunk (rev. 7027), will be in 4.4alpha2
- TYPO3-4_3 (rev. 7028), will be in 4.3.3
- TYPO3-4_2 (rev. 7029), will be in 4.2.13
- TYPO3-4_1 (rev. 7030), will be (maybe) in 4.1.14.