[TYPO3-v4] feedback on configurable cookie names

[Christian Jul Jensen]

Hi.

I am implementing support for configurable cookienames to fix some 
issues with clashing cookies between installations on same domain.
http://forge.typo3.org/issues/23872

I have it basically working but have run into a problem:

The presence of a backend cookie in the frontend is used to determine 
whether or not to enable the timetrack or to use a stub.

This happens before the inclusion of the configurations as the 
timetracker is used to track the time of the inclusion of these.

Now that I have moved the BE cookie name to be a configuration it is no 
longer possible to use this as a flag to indicate whether or not to 
enable timetracking at that point.

I've played around with different ideas, but are not really happy with 
any of them, so I'd appreciate some feedback on this.

a) Do not start the timetracking until after the inclusion of 
configurations.
* cons: the inclusion is not measured

b) Initalize timetracking always, but abort it once we know a BE-user is 
not present
* cons: I guess most of the time gained by having a stub could be lost 
doing this, but I am not sure.

c) use some other flag to indicate whether or not to timetrack. AFAIK 
timetracking is only used by the adminPanel and the config.debig option 
and so it is kind of silly anyway to initialize everytime a BE-user is 
logged in.
* Problems: Which flag to use? How to make sure it is available at the 
time needed. It would be possible to have the admPanel set a seperate 
cookie, but this would happen after timetracking is initialized so it 
would not be available on the first request, which might lead to some 
confusion.

-- 
Christian Jul Jensen
julle at typo3.org

TYPO3 Evangelist
Member of the TYPO3 Association Steering Committee