TYPO3 Core

Next:

If [FE][lifetime] ist set a value > 0 the problem seems to be solved - i have not figured out why, but it is.

The description is a bit odd there: "[lifetime] Integer, positive. If >0, the cookie of FE users will have a lifetime of the number of seconds this value indicates. Otherwise it will be a session cookie (deleted when browser is shut down). Setting this value to 604800 will result in automatic login of FE users during a whole week, 86400 will keep the FE users logged in for a day."

Sum that up:
If the value is 0, the cookie is a session cookie (but changes on every refresh).

If the value is > 0, the cookie should have a lifetime (in fact, it has not - until, the user logs in - before, the cookie is a session cookie)

If the value is > 0 and user logs in, the cookie is changed to a cookie with the definied lifetime - an fe_sessions entry is created. If the user logs out now, the cookie will still stay a cookie with lifetime but the fe_sessions entry is deleted. So you still have your cookie - with, say 3 months of lifetime, but the session-entry is already killed.

Whats the point of this?

Solutions:
fix the description of [FE][lifetime]
fix the behavior of session cookies for logged in and not logged in users (different lifetime for not logged in users, lifetime for logged in users)

Why is a changing fe_typo_user a problem for you? As long as there's no FE user session, there's no need to "identify" a user.
Using TYPO3's API, you can read/set data to a FE user session (even if the user is not logged in).

So if a changing fe_typo_user value hurts you in any way, the extension does not properly use TYPO3's API but cooks it own soup.

FYI: As I don't see a bug here, I intend to close this report.

fe_typo_user behaved allways like PHPSESSID, for many applications it's essential to identify a single user session, even if the user is not logged in (see http://en.wikipedia.org/wiki/Session_(computer_science)#HTTP_session_token for example)

for example in webshops - without an identification criteria (wich a "session" should be) it's not possible to identify a user within his session. usualy the basket is bound to the users session - if he leaves the page, the session cookie and the basket is lost, thats ok. but the user should not use his basket by clicking a link.

i still have no explaination, why a changing fe_typo_user (let's call it "session cookie", since the documentation in the install tool states this) is security relevant. any other system i know has a static session cookie value (the only single use of a session cookie) - even the internal PHPSESSID - and thats ok for security reasons.

if it won't be changed - what reason ever: change the documentation, is wrong then - fe_typo_user is not a true session cookie then and cannot be used for storing session information - if the user is not logged in, is pretty useless.

and of course: would you mind to explain my, how i can use the TYPO3 API correct and identify a non logged in user with a changing session cookie?

according to #19831 the first problem was: TYPO3 accepted custom session ids, sure thats security relevant. but rotation the session-value is imho a bad solution.

the better solution will be creating an entry in fe_sessions even for not logged in users (just like the php-internal-session handling behaves) - ses_userid could be set to 0 or -1 for this purpose to distinguish a logged in and a not logged in fe_user

if the sent cookie does not match any ses_id in the table, it can be refused. if the sent cookie matches a ses_id in the table and complies with other criteria - like iplock, hashlock and is still within its valid lifetime, it can be delivered to $GLOBALS['TSFE']->fe_user->id

currently "isExistingSessionRecord" does not check, if the session is valid, that could be easyly expanded

the changing cookie is annoying and confusing but not the real problem - i'm ok with a changing cookie value, but "$GLOBALS['TSFE']->fe_user->id" should stay the same within a session - the term "id" implies this.

would you mind to explain my, how i can use the TYPO3 API correct and identify a non logged in user with a changing session cookie?

I said "Using TYPO3's API, you can read/set data to a FE user session (even if the user is not logged in)"
http://typo3.org/documentation/document-library/core-documentation/doc_core_tsref/4.4.0/view/1/13/#id2538611
this works for session- and user-data

Probably, in no other web application you use session_id() to work on the ID itself. No, you'll use $_SESSION to store/read session information. You don't care about the session ID. The TYPO3 API allows that - see documentation link above.

Why session handling is now the way it is:
Sometimes, you have democratic decisions in developer teams. Back then, a majority voted to don't care about the SID and so it's cycling as long as you don't store data.
Side note: In the discussion, I expressed my wish to have constant SIDs. ;-)
But, that's life I guess.

If you really want constant SIDs, I hereby encourage you to provide a patch. Test it properly (also in regards to not re-introducing old vulnerabilities) and send it to the core list as RFC!

aww - i just wrote a load of text - browser crashed. i swear, i'll never use firefox again and stick to opera :p

sum up:

- changing session id is not a security problem
- security problem in TYPO3 just was fixed dirty by doing so

providing a patch will be much more work than simply setting a value in the session (just for the sake to have one) and using this further ;)

I see. Closed, no change required.