Feature #23872
closedRenaming of FE cookie name
Added by Markus Blaschke almost 14 years ago. Updated about 11 years ago.
100%
Description
Allow renaming of FE Cookie Name, because currently it's not possible to host multiple TYPO3 installations on the domain if two or more subdomains are shared by one installation, eg.:
www.example.com (TYPO3 Installation #1)
foo.example.com (TYPO3 Installation #1)
bar.example.com (TYPO3 Installation #2)
foobar.example.com (TYPO3 Installation #3)
If in the "TYPO3 installation #1" the CookeDomain is set to:
$TYPO3_CONF_VARS['SYS']['cookieDomain'] = '.example.com';
The user will be logged in in www.example.com and foo.example.com, but is unable to login in bar.example.com and foobar.example.com.
Both, FE-Login and BE-Login fails (with Firefox 3.6.x).
The best sollution would be the renaming of the FE/BE-Cookie name.
Would be nice to see this feature in 4.5 LTE.
(issue imported from #M16171)
Updated by Markus Blaschke over 13 years ago
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!?).
Updated by Christian Jul Jensen over 13 years ago
- Target version deleted (
0)
The problem is actually the fix made to make a workaround for an IE8 bug in the getCookie function in t3lib_userauth which makes TYPO3 handle cookies in a way that is not compliant with RFC 2109 http://www.ietf.org/rfc/rfc2109.txt
According to the RFC the browser should serve the cookie with the most specific path for first, and the server should always use the first cookie in an event of nameclash. That is correctly handled by PHPs cookie function, but TYPO3 reads it directly out of the header and uses the last one served,
I agree that the best solution would be rename the cookies to be unique for each installation, alternatively make an option to disable the IE8 workaround in case of more TYPO3 installations on the same domain.
Updated by Markus Blaschke over 13 years ago
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.
Updated by Christian Jul Jensen over 13 years ago
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.
Updated by Ernesto Baschny over 13 years ago
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.
Updated by Christian Jul Jensen over 13 years ago
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.
Updated by Ernesto Baschny over 13 years ago
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
Updated by Christian Jul Jensen over 13 years ago
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 :)
Updated by Benni Mack over 13 years ago
However, all in all: Having an option to name the cookie should be important in any case.
Updated by Christian Jul Jensen over 13 years ago
- Assignee set to Christian Jul Jensen
Updated by Christian Jul Jensen about 13 years ago
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.
Updated by Mr. Hudson about 13 years ago
Patch set 1 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373
Updated by Christian Jul Jensen about 13 years ago
- Status changed from New to Under Review
- Target version set to 4.6.0
Updated by Mr. Hudson about 13 years ago
Patch set 2 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373
Updated by Mr. Hudson about 13 years ago
Patch set 3 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373
Updated by Mr. Hudson about 13 years ago
Patch set 4 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373
Updated by Mr. Hudson about 13 years ago
Patch set 5 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373
Updated by Mr. Hudson about 13 years ago
Patch set 6 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373
Updated by Mr. Hudson about 13 years ago
Patch set 7 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373
Updated by Mr. Hudson about 13 years ago
Patch set 8 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373
Updated by Mr. Hudson about 13 years ago
Patch set 9 of change I8078bd284cdf5d1413ddce8bc004e25f855ba6c5 has been pushed to the review server.
It is available at http://review.typo3.org/2373
Updated by Christian Jul Jensen about 13 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 40170c36ca2424dacd208cc68756ae8778ad6143.
Updated by Xavier Perseguers about 13 years ago
- Target version changed from 4.6.0 to 1281
Updated by Xavier Perseguers over 12 years ago
- Status changed from Resolved to Closed