Lazy session start

[weierophinney]

The current container object starts a session in the constructor automatically. This works fine for most use cases, but it could come in handy to use some kind of delayed session start. I'm working on a REST API which accepts API keys, but also check for authenticated users in their sessions. The authentication for the users are stored in sessions. However, every API call from a REST client generates a session. It will send a cookie to the REST client, while also storing the session information on disk. This should not happen with every API call by REST clients.

It would be great to have a container which does not automatically starts a session, only under the following circumstances:

• If data is written to the container, start a new session
• If trying to read data from the container, only start a session when session_status return PHP_SESSION_NONE and $_COOKIE[session_name()] is set. This will only start a session when the browser actually has send a cookie to the server.

---

Originally posted by @dekker-m at https://github.com/zendframework/zend-session/issues/43

[weierophinney]

I've the same problem on my application. Do you have any idea how to resolve this problem properly ?

---

Originally posted by @mael-lg at https://github.com/zendframework/zend-session/issues/43#issuecomment-355919923

[weierophinney]

Containers should not be injected, but rather requested at runtime. Session containers are NOT services.

---

Originally posted by @Ocramius at https://github.com/zendframework/zend-session/issues/43#issuecomment-355921994

[odan]

I have the same issue with this session package in combination with a DI container. Creating a session or a Laminas\Session\Container object should not start the session handler. This is important, because the session start needs to be controlled by e.g. a middleware. I guess the problem is here:

• https://github.com/laminas/laminas-session/blob/2.14.x/src/AbstractContainer.php#L85

 // Start session
$this->getManager()->start();

If this line could be removed, the issue could be solved. But I guess this would be a breaking change.