Bug #29927

Remove occurences of session_start()

Added by Daniel Poetzinger about 8 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2011-09-17
Due date:
% Done:

0%

TYPO3 Version:
4.6
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

TYPO3 has its own session management and per default it should not be required to use an additonal PHP session.

Currently session_start() calles are spread around in the core which is really sad (that wasn't the case in earlier TYPO3 versions).
Since it opens a frontend session for every request to the page. (TYPO3 session management is more intelligent here)
This results in many tmp files (PHP session) and a default PHPSESSION cookie.

examples:
typo3/index.php: session_start()
t3lib/class.t3lib_userauth.php: session_start();
...

I understand that the phpsession is required by rsa auth (but even here the TYPO3 session could be used imho).
But it would be great if it could be removed everywhere else.


Related issues

Related to TYPO3 Core - Bug #29274: Regression on session handling for security fix Closed 2011-08-26

History

#1 Updated by Chris topher about 8 years ago

  • Subject changed from no use of session_start() per default to Remove occurences of session_start()

#2 Updated by Helmut Hummel about 8 years ago

  • Status changed from New to Needs Feedback

I agree, that a PHP session must not be started for every frontend request. This is a bug, which is addressed in #29274

Can you check if the bugfix there solves your issue?

For authentication there is no way around using the php session because, the TYPO3 (backend-) session is bound to an authenticated user.
In the PHP session the challenge ("normal" be-login, which is btw. the case since version 3.8 or so) or one part of the rsa private key is stored.

I agree that the whole session management needs a cleanup, but this is
a) a huge task
b) not reasonable to just remove all usage of the PHP session.

So if #29274 fixes your problem in the frontend I would rather close this ticket and go for small steps in revamping the session management starting from version 4.7.

#3 Updated by Christian Kuhn almost 8 years ago

  • Status changed from Needs Feedback to Closed

Closed after a month since the issue is also tackled with the related issue.

Also available in: Atom PDF