Create containers from request objects rather than from superglobals

[MidnightDesign]

Are there any plans (3.0?) to switch to creating session containers from PSR-7 request objects rather than relying on PHP's superglobals?

I hope I'm being clear enough. If not, let me know and I'll try to clarify.

[Ocramius]

Just a personal opinion:

I would suggest moving this over to https://github.com/Ocramius/PSR7Session first

I can gladly donate that component to ZendFramework, if the security team is willing to take over on security maintenance, and if @malukenho and @lcobucci agree and can help maintaining it here.

[lcobucci]

@Ocramius I totally agree

[MidnightDesign]

@Ocramius What do you mean by "moving this over" exactly? This conversation? This ZF component?

[Ocramius]

@MidnightDesign as in discuss there what you want, then we can import that component into ZF3/4/5/whatever when we think we got something decent at PSR-7 compliance level.

[MidnightDesign]

@Ocramius I don't know if your project is what I'm looking for. Ist it supposed to stay storage-less? Isn't it too specialized for the Middleware use case?

I'm looking for something generic like $sessionManager->fromRequest($request).

[weierophinney]

@MidnightDesign I'm not entirely sure I understand this sentence:

switch to creating session containers from PSR-7 request objects rather than relying on PHP's superglobals

PSR-7 does not provide any facilities around sessions. We did this as the only part of sessions that have anything to do with HTTP messages are the cookies passed back and forth, which are simply identifiers that can then be used server-side to persist information. The data currently would need to come from some sort of storage — whether that's ext/session, or something else. This latter is why we didn't incorporate session information in PSR-7; when you're not using an SAPI (for instance, with async systems like React, Icicle, or Aerys), ext/session is not available, which means sessions are handled at the application level. In other words, the only aspect of sessions that PSR-7 requests can guarantee are the cookies themselves.

What https://github.com/Ocramius/PSR7Session does is essentially cookie-based JWT. The session information is de-serialized from the client-side cookie and then injected into a stateful request attribute — which is a clever approach, as it gets around the request immutability, allowing the same middleware to then serialize the data for the cookie to return to the client once the response is complete. It's similar to what you're suggesting, @MidnightDesign, but likely not in the way you originally were thinking. It's not exactly specific to middleware, either; as long as you have access to the request cookie value, and can set response cookies, it would work; it would not take much to adapt it to work in zend-mvc (more on that further into this comment).

@Ocramius — I would be quite happy to bring the component into the zendframework organization. The only issues:

• MIT vs BSD-3-Clause license. These are compatible, but we are trying to have a single license for all ZF components.
• Ideally, I'd like one or more of the developers to join the ZF security team, so that we have a subject matter expert who can assist with evaluating and/or fixing any reported potential vulnerabilities.

In terms of getting this into ZF3: obviously, it'd be useful immediately with zend-expressive. We'd likely need to create some additional facilities to make this work with zend-mvc, but I don't think it would be terribly difficult. The bigger issue with using it in zend-mvc would be the fact that it's a very different design from the current zend-session component, which would have implications on things like the FlashMessenger, zend-captcha, etc. These are solvable problems, but will likely need to wait for later 3.X releases of affected components, or potentially even 4.X releases (one nice thing about the ZF3 initiative is that we can accelerate how often major releases occur).

[Ocramius]

@MidnightDesign psr7-sessions/storageless#21

[Ocramius]

MIT vs BSD-3-Clause license. These are compatible, but we are trying to have a single license for all ZF components.

Migrating to BSD-3-Clause is as simple as find/replace (and allowed)

Ideally, I'd like one or more of the developers to join the ZF security team, so that we have a subject matter expert who can assist with evaluating and/or fixing any reported potential vulnerabilities.

Fully agree: actually asked for it initially.

[MidnightDesign]

@weierophinney Yup. Thought I wasn't clear enough.

My main concern is with long-running applications that deal with multiple requests. In such an environment we obviously can't rely on some global variables to carry session IDs. That's why I mentioned PSR-7, as it could be a common object some SessionManager gets its session identifier from:

$sessionManager = new SessionManager();
$sessionManager->setCookieKey('PHPSESSID');
$session = $sessionManager->getSession($request);

...or something along those lines. Basically, it would be like passing getSession() the session ID, but also giving it the freedom to grab the ID from whereever it wants on the request object.

I wasn't thinking about some client-side cookie at all. Bad title. I'm talking about a Session component for environments with multiple requests.

[weierophinney]

This repository has been closed and moved to laminas/laminas-session; a new issue has been opened at laminas/laminas-session#24.