Bug #65187
closed
Having nested installations makes BE login fail with no error message
100%
Description
Consider a setup like this:
webroot/firstInstance webroot/firstInstance/secondInstance
Logging into BE of firstInstance causes "be_typo_user" cookie to be set, with path /firstInstance.
Trying to log in into secondInstance sets another "be_typo_user" cookie with path /firstInstance/secondInstance.
When \TYPO3\CMS\Core\Authentication\AbstractUserAuthentication::getCookie tries to evaluate the cookie, it uses $_SERVER['HTTP_COOKIE'], the raw cookie string, which contains both cookies then for the secondInstance.
The loop in getCookie() selects the last cookie found, which seems to be the one for /firstInstance.
All tests currently showed that the browser seems to send the more specific (path-wise) cookie first. So a solution might be to change the logic to select the first cookie found.
http://stackoverflow.com/a/24214538 cites RFC sections which suggest the user-agents to send more specific cookies first, but on the other hand also suggest that the server shall not rely on this.
Test show that all major browsers in the current version actually follow this guideline. It is therefore at least "more correct" to select the first cookie instead of the last.
Updated by Gerrit Code Review about 9 years ago
- Status changed from Accepted 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 http://review.typo3.org/37030
Updated by Gerrit Code Review about 9 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/37030
Updated by Markus Klein about 9 years ago
- Description updated (diff)
- Assignee set to Markus Klein
Updated by Markus Klein about 9 years ago
http://stackoverflow.com/questions/2638344/ie-sends-multiple-cookies-with-same-name
says something about IE8 behaviour which is mentioned in the code comment.
IMO this is not a bug, ok, one just needs to set cookie-domain correctly.
Hence I opt for removing this code again and switch back to normal $_COOKIE processing.
Updated by Markus Klein about 9 years ago
#22084 is the original ticket
Ernesto describes the issue very clearly in https://forge.typo3.org/issues/22084#note-4
BUT Dmitry already discovered 3 years ago that the merged fix is inappropriate: https://forge.typo3.org/issues/22084#note-14
One thing is important to note: Ernesto talks about cookies being set in FE although no session data exists and new cookie being set for every request. This behaviour is NOT the case anymore. We do not set any cookie anymore unless session data or login is present, so this should not be an issue anymore.
Updated by Gerrit Code Review about 9 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/37030
Updated by Helmut Hummel about 9 years ago
Markus Klein wrote:
#22084 is the original ticket
Thanks for digging that up. I agree that the workaround is not needed any more, since 6.2. I adapted the change accordingly.
To be sure to not break things, we should keep the method when adding this patch to 6.2
Updated by Gerrit Code Review about 9 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/37030
Updated by Gerrit Code Review about 9 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/37030
Updated by Gerrit Code Review about 9 years ago
Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/37282
Updated by Helmut Hummel about 9 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset a54be70d39ac5cd47ed3c93d44e728c92b89545c.
Updated by