TYPO3 Core

If any browser (eg. firefox/google chrome) access one TYPO3 installations with a subdomain-cookie-setting (eg. ".example.com"), all other TYPO3 installations under this domain are NOT USEABLE anymore.

BE-Login fails without error, user will be redirected to login-page instead of BE.

It blocks the whole backend until the browser is restarted (maybe it could be use to DoS any TYPO3 installation!?).

IMHO the only way to fix this would be a option to rename the cookies.

This cookie problem is still a big issue in TYPO3 in multi-installation and subdomain hosting.

I will fix this, but want to make sure that I implement it in a way that is agreed on by the core team. I started a thread in typo3.dev.

Julle, please check #22084 and the note I added about why this fix was required for it to work with IE8. We we having BE-logouts without the fix and the reason is explained there.

Thanks Ernesto, I realized that was the case. Still the fix breaks other scenarios and makes TYPO3 uncompliant, I think the use of the workaround should at least be configurable, but I think the best solution is to generate an installation specific cookie-name.

Jully, according to the bug description, I don't see the relation.

If you have multiple domains and set the following "cookie domain" on any of them:

$TYPO3_CONF_VARS['SYS']['cookieDomain'] = '.example.com';

It is obvious that the cookie will be shared across all domains. This is just a misconfigured scenario.

Multiple installations under different subdomains should not share the same cookie domain:

bar.example.com = $TYPO3_CONF_VARS['SYS']['cookieDomain'] = 'bar.example.com';
www.example.com = $TYPO3_CONF_VARS['SYS']['cookieDomain'] = 'www.example.com';
etc.

To simplify, you could set on all domains:

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

Which would place the current domain as the cookie domain.

So maybe your problem is of a different nature than the original reporter?

Cheers,
Ernesto

Sorry. Yes it is slightly different.

If you are hosting 2 TYPO3 installations within the same path let's say www.mydomain.tld (upper site) and www.mydomain.tld/subsite/ (lower site) 2 cookies will be set with same name. When visiting the lower site the browser should send both back to the server since they both match the domain and path. The cookie with the most specific path (lower site) should be first in the http headers.

In the case of a name clash, the server must choose the first one in order to use the that is most specific. This is how it is defined and should work.

Because of the bug in IE8 we always use the last one, which is wrong and makes session-handling buggy in a setup like this.

The easiest way would be to take the path into consideration when choosing the right cookie, but unfortunately that is not sent by the browser, so the only thing you have to rely on is the order in the headers sent.

As I see it there are 2 solutions.

1: Make the IE8 fix configurable
or
2: Make the cookie name unique across installations

Option 2. would be the right one in my pov, and also fix the other issues mentioned here, but it is also the solution that imposes the biggest risk if somebody relies on the cookie name.

Also I have a feeling that the 'sudden log out' problems some experience might related to this, but I am not sure.

One of our clients have this problem and I need to fix it, but I want to make sure I implement a solution that gets back into the core so they can keep their installations upgradeable. For the time being I just disabled the IE8 hack

Hope that makes more sense :)

However, all in all: Having an option to name the cookie should be important in any case.

I have implemented custom naming of cookies now, but've come across an issue that I am not sure which way to go.

In index_ts.php the existence of a BE-cookie is used to decide whether or not to activate time-tracking (line 107). Since time-tracking also covers the inclusion of configurations (line 132) it is not possible to determine the name of the cookie at this point.

As I see it there are 2 possible solutions:

a) move the initialization of the time-tracking to after inclusion of configurations

b) use some other flag to determine whether or not to initialize time-tracking

In my pov b) would be the right choice, in fact I don't see why the timetracker is used every time a BE-cookie is present, it would make sense to only start when using the admPanel. I am not sure if the admPanel sets a cookie or something other to check on.

Patch set 1 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373

Patch set 2 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373

Patch set 3 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373

Patch set 4 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373

Patch set 5 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373

Patch set 6 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373

Patch set 7 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373

Patch set 8 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373

Patch set 9 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373