Bug #19916

Session handling - cannot login to >1 TYPO3 installation under one domain

Added by Tomas Mrozek over 6 years ago. Updated about 5 years ago.

Status:Closed Start date:2009-01-26
Priority:Should have Due date:
Assigned To:Marcus Krause % Done:

0%

Category:- Spent time: -
Target version:-
TYPO3 Version:4.2 Is Regression:
PHP Version:5.2 Sprint Focus:
Complexity:

Description

With the new session handling introduced in 4.2.4 it is no longer possible to login (at the same time) to two or more TYPO3 installations located in different subfolders of the same (sub)domain.
In other words, access to one installation breaks the session of the other(s).

TYPO3 should handle sessions according to the exact path of the TYPO3 (sub)folder within the domain.

I think that it's a significant change of behavior within the current branch that creates a problem for administrators.
(issue imported from #M10266)

10266.diff Magnifier (6 kB) Administrator Admin, 2009-03-15 12:39

10266_v3.diff Magnifier (6.1 kB) Administrator Admin, 2009-03-22 09:41


Related issues

related to Core - Bug #19879: after upgrade from 4.1.7 to 4.1.8 feusers and beusers hav... Resolved 2009-01-21
related to Core - Bug #19908: session fixation fix avoid BE login Resolved 2009-01-25
related to Core - Bug #19912: The Bug 0010205 "DB session records are only created whe... Resolved 2009-01-25
related to Core - Bug #19883: timout after backend login in 4.2.4 Resolved 2009-01-21

History

#1 Updated by Marcus Krause over 6 years ago

The only possible solution (which isn't implemented and therefore currently not working) is to limit each session id cookie to the subfolder, TYPO3 is existing in.
Example:
example.org/cms1/
example.org/cms2/

#2 Updated by Thomas Schröder over 6 years ago

I can confirm this behavior with TYPO3 4.2.5, FF3, IE7. Steffens workarround in bug #19908 works also fine for this bug.

Edit: I have to correct me. Steffens workarround #19908 does not solve the problem.

#3 Updated by Luc Germain over 6 years ago

This problem is also present in 4.1 since 4.1.8.

#4 Updated by Mathias Brodala over 6 years ago

I can confirm this issue in 4.1.10. Please consider fixing this. Maybe putting additional info into the cookies to distinguish them is possible.

#5 Updated by Marcus Krause over 6 years ago

added patch that set path parameter to setcookie() calls whenever possible

#6 Updated by Thomas Schröder over 6 years ago

The patch v3 works fine for me. Tested with 4.2.7-dev and 4.3-dev (latest rel.) on 3 installations.

#7 Updated by Christian Kuhn over 6 years ago

Committed to

  • 4.1 (r5299)
  • 4.2 (r5300)
  • trunk (r5301)

Also available in: Atom PDF