PSR-7/PSR-15 Sessions

[Amanda]

Hi ,

Hope everybody is well in these continued crazy and challenging times.

It would be great to have a PSR for Sessions to complete the other PSRs and fill gaps by not having a standard session interface.

I have attached a document outlining some thoughts and ideas about what i think might be needed and things to be considered based upon my research and testing, which can be used as a starting point for discussion.

It would be amazing if the leading frameworks can come together to write this much needed PSR.

Are there any representatives from frameworks here who are interested in making this happen and backing this? 🙏

Amanda

[Ralf Lang]

Hello Amanda,

as discussed on the chat I am very much interested in that activity.
I have been doing preliminary research on the different session solutions in mainstream frameworks.
Last year I did a PSR-7/15/17/18 implementation based on the Horde framework and modernized session handling is already on my list. Discussion on an upcoming standard and implementing it in that context would just fit in.

However, I am speaking as an individual contributor, not speaking as a representative of Horde. That would be Jan Schneider's role.

Looking forward to participate.

Regards

Ralf

[Vinnie Marone]

I am very much interested in this. I think this is something the php community has needed for a very long time.

I have some other design specs as well, and look forward to seeing us all come together with something we will be happy to present to the PHP Community.

Regards,

Vinnie 

[Amanda]

Thanks for your interest, I also agree that the PHP community needs this very much. 

The code in my proposal is an example and proof that we can make everything work together.

The purpose of the working group is to come up with a solution together that can be used by everybody.

Once a working group has been formed (and we have a sponsor), a detailed proposal will be written, then the working group would start from a blank canvas  

as it would be clearer then what will be covered and what won't in this PSR. 

Does anybody know if we need a sponsor to form the working group, or do we need to form the working group to get the sponsor, it is not clear.

Ideally I was hoping for representatives from other frameworks to be part of this working group, anybody here?

Amanda

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/47aad66e-89cf-4f9a-b536-e925d8324488n%40googlegroups.com.

[Larry Garfield]

On Thu, Sep 29, 2022, at 3:14 AM, Amanda wrote:
> Thanks for your interest, I also agree that the PHP community needs
> this very much.
>
> The code in my proposal is an example and proof that we can make
> everything work together.
>
> The purpose of the working group is to come up with a solution together
> that can be used by everybody.
>
> Once a working group has been formed (and we have a sponsor), a
> detailed proposal will be written, then the working group would start
> from a blank canvas
> as it would be clearer then what will be covered and what won't in this
> PSR.
>
> Does anybody know if we need a sponsor to form the working group, or do
> we need to form the working group to get the sponsor, it is not clear.
>
> Ideally I was hoping for representatives from other frameworks to be
> part of this working group, anybody here?
>
> Amanda

The formal formation of a working group includes "here's the basic skeleton of a PSR and what it hopes to do, here's the members of the working group including a Sponsor, Core Committee please vote to charter us."

So a Sponsor is needed prior to the Entrance Vote.

--Larry Garfield

[Paul Dragoonis]

Hi Amanda,

Ask yourself. What problem in the community are you solving? 

We don't want to make standards for the sake of it. 

Are people actively trying to write code in Symfony that doesn't wanna use Symfony sessions? 

Figure out the demand first, validate it, present some info.

I'm not a blocker here in this process, I'm just asking you to have a think. 

When we started this group (fig) we were wanting to make standards for all sorts of things, including sessions, but after we done the market analysis we realised the masses were not really interested in adopting a generic session standard. 

If the appetite has changed, then let's do it.

Food for thought. 

Cheers,

Paul

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/7e8a2e90-efe7-4900-b7f6-d221fd7b2607%40app.fastmail.com.

[Amanda]

Hi Paul,

Thanks for writing back. 

I actually presented this idea on the discord channel about a year ago first, and at the time people expressed interest, just this week people on discord channel it was brought up by somebody else. 

In a PHP chat channel of 6,000 members , I frequently come across the problem where people want or need to switch out the framework session library for one reason or another, e.g they want to start using swoole or they companies want to decouple their code from the frameworks that they are using, having a PSR for sessions, makes swapping out stuff every easy.  Also in this day and age companies are using multiple frameworks for their projects, in most cases those projects work with sessions, and it would be nice if we did not have to learn all the different session libraries for each framework.

Furthermore, in most PHP frameworks including symfony and even frameworks in other languages such as java (https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletRequest.html) , they all have a getSession method, as this is part of the request. So having a standard for sessions to complete the existing PSRs is another reason. 

Also what is the point of learning how to use a PSR request or response object then you pull a different session object from it each time, we all look for the session object there now.

I actually had the idea when writing a integration testing suite for applications that use the PSRs, its gets messy when working with sessions because there is no standard way, there are standard requests, standard responses, standard request handling, but no standard for storing data between requests, and PHP sessions dont work nicely with  PSR 7 response objects, so by having a standard we dont need to worry about that anymore.

Amanda.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKxcST9B5Rp-tK_q4e7-45nhvO1qcyiBVQTqsjhsTTgJqjCVKw%40mail.gmail.com.

[Paul Dragoonis]

On Thu, 29 Sep 2022, 20:51 Amanda, <amanda...@gmail.com> wrote:

Hi Paul,

Thanks for writing back. 

Hi Amanda,

Good reply!

Which chat room has 6000 people ? 

Maybe dont couple it to PSR-7 tho. 

That means people have to use and adopt 2 standards to use 1. Keep it independent. 

We thought about this before, and we realised this wasnt the best idea. 

Keep up the energy 💪 looking forward to seeing the progress. 

Many thanks,

Paul

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAP2uk-B8tF51QgYMjMkOFYbxzFXR20Bqs_%2BR%3DKP31kKrohygDg%40mail.gmail.com.

[Ralf Lang]

Hi everybody,

Am 29.09.2022 um 22:31 schrieb Paul Dragoonis:
>
> Maybe dont couple it to PSR-7 tho.
>
> That means people have to use and adopt 2 standards to use 1. Keep it
> independent.
>
> We thought about this before, and we realised this wasnt the best idea.
>
> Keep up the energy 💪 looking forward to seeing the progress.
>
> Many thanks,
> Paul
>

I understand from what I have read that the coupling between the
middleware interface and the session interface itself comes from the
original problem they wanted to solve.
At least that is my interpretation. Mind the subject line of this
discussion.
While a common session interface (or session handler interface, that's
quite a debate) is beneficial by itself, it still leaves room for
incompatibility in PSR-7 messages in PSR-15 context.

If the guiding question is "How does a HTTP middleware access and query
a session", then this gap makes sense to address. It could be as little
as "a middleware consuming the session SHOULD retrieve it from a request
attribute named 'PSR\Session'. A missing session object SHOULD ..." -
treat this as a lorem ipsum.

Just thinking.

[Amanda]

Paul,

The chat I was referring to is the PHP slack channel, it has 6k members but it is not as active as it was before covid.

I think the symfony slack channel has 21k members and larachat channel claims to have 36k members.

Amanda

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKxcST9EuECoeoVeHdOK5twgotB7toamvgEchbHj96psw17OxQ%40mail.gmail.com.

[Vinnie Marone]

Hey all,

I feel coupling the interface alone to a PSR7 implementation would defeat the overall purpose of this. My original intention when I had brought this up last week which led to this conversation being started again, was the fact that working with sessions and testing in php is not entirely great since it emits headers (yes there are options to turn these off before you start the session). But that doesn't stop the fact that it is a clunky mess as it forces developers to have to use $_SESSION(in some capacity, even if you just wrap it in a singleton) which depending on who you ask is fine or isn't as they hate globals.

What I find cool about removing it from the global state entirely is that a developer now has the flexibility to query multiple sessions with ease of instantiating a new object. Not sure why anyone would wanna do that but again it gives them the flexibility to do so easily.

I think the psr should stand alone. Do 1 thing and 1 thing alone. Manage a session implementation that does not emit any headers. Leave this up to the libraries and or developers on how to do that.

Obviously if you do that and make it independent as paul is suggesting. It not only allows someone to make the decision to use a PSR7 implementation or use something else entirely.

I've added a rough draft with more functions and more interfaces. Decoupling the SessionInterface away from the storage engine that would be used.

https://github.com/Porthorian/fig-standards/blob/master/proposed/session.md

Vinnie 

[Amanda]

Vince,

Firstly, I don't think it was correct or professional of you to submit a separate proposal for PHP sessions without me to the PHP fig repo, basically sidestepping and ignoring my work and effort, i feel this was really disrespectful. 

Secondly, I believe the CC members want to see interest and buy in from other frameworks. 

IMHO. Looking at your submission think are too many interfaces  and the session interface is way too polluted for a PSR (e.g. getIssuedAt getRepo, setRepo, resume, migrate etc) and very it limiting for anybody who wants to implement it, it removes the freedom from the frameworks to do their own thing,restricting design and creativity without offering much benefit, it's basically looks like a set of interfaces from a library and therefore you would be enforcing a library design. This is not a PSR is about.

As a framework writer I would not like this, and I don't think the PSR should cover the backend. If the session interface is attached to a handler by design and people drop that in, then so be it - same as PSR log, that is the beauty of the PSRs.

If you take a look at the PSRs you will see and appreciate the beauty in the simplicity.

My submission to this group was based on the idea to try and gather interest from other parties  to get backing, discussing design here is irrelevant, this must be done by the working group when formed, that is what a working group is for.  My proposal was based upon the minimum requirements that I think needs to be covered by the PSR (and some things which i think are cool standarding session cookie name and token etc), but only once a working group can be formed and agreement can be made on what problems are being solved and what will be covered and what not then the interfaces can be designed properly. 

Amanda

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/c2f15154-f8bf-439d-95fa-07042955d3c3n%40googlegroups.com.

[Vinnie Marone]

Hello Amanda,

I am sorry you feel that way and apologies for any sort of disrespect you may have felt. However, I would like to clarify a few things.

I did not submit a pull request to the PHP-FIG repository. I simply forked it and created the README.md so I could add it to this email list. It is my mistake that I assumed this was where we would discuss designs of our vision of how PHP sessions would be handled. For that I am sorry.

With that out of the way.

I think we should now start discussing moving more towards a working group rather than critiquing individual proposals in detail. Any future proposals or design talk without a working group is more of a moot point. For that I apologies for bringing us down this road. But the discussion does need to move towards a working group.

To that end, I have reached out to Taylor Otwell from Laravel and Nicolas Grekas from Symfony. To see if they are interested in seeing a PSR session standardization across PHP. If either of them decide that it is not worth their companies time. Then this will not even make it to a working group.

Vinnie 

[Vinnie Marone]

Hey All,

So I got into contact with Nicholas Grekas from Symfony. He believes that the interop already provided by PHP at the handler level is good enough and I would assume they arn't interested to even consider the conversation of adopting any sort of PSR standard.

So to that end, not sure where we go from here. But I think that sums up the possibility of even getting to a working group.

Thanks,

Vinnie

[Rasmus Schultz]

Hi Amanda,

I'm interested in this, and I mostly agree with your approach and philosophy.

I did some work today trying to move this idea forward, and would propose some changes.

First, I'd like to replace the mutable ServerRequestSessionInterface with an immutable SessionManagerInterface, which would be responsible for:

1. opening the session: parsing session cookies and obtaining the stored session data.
2. committing the session: applying the session cookies and storing the session data.

This seems to be more in tune with PSR-7/15 and makes it obvious how to integrate them.

use Psr\Http\Message\ServerRequestInterface; use Psr\Http\Message\ResponseInterface; interface SessionManagerInterface { /** * Initiates a new session or resumes an existing session based on the request context. * * @param ServerRequestInterface $request * * @return SessionInterface */ public function open(ServerRequestInterface $request): SessionInterface; /** * Commits session data to storage and applies session cookies to the response. * * @param SessionInterface $session * @param ResponseInterface $response * * @return ResponseInterface */ public function commit(SessionInterface $session, ResponseInterface $response): ResponseInterface; }

Secondly, I'd propose some changes to simplify the SessionInterface to clarify its role as the bearer session state (and session identifier) and simplifying its semantics:

1. Removing the start and close methods - this is the responsibility of the SessionManagerInterface service, and should happen implicitly.
2. Removing the getId method - leaving session identifiers as an implementation detail of the SessionManagerInterface service.
3. Changing the return type of regenerateId from bool to void. (it always returned true.)
4. Added a getAll method, allowing the session values to be enumerated.
5. Removed clear in favor of destroy, as these are are ambiguous and can be confusing - to my knowledge, there is no reason you would clear the session data without also destroying the session? If you're clearing the session data anyway, you might as well generate a new session identifier to avoid creating a secuity risk.

interface SessionInterface { /** * Retrieves a session value associated with a given key. * * @param string $key * @param mixed $default Default value if the session key does not exist. * * @return mixed */ public function get(string $key, mixed $default = null): mixed; /** * Sets a session value for a given key. * * @param string $key * @param mixed $value */ public function set(string $key, mixed $value): void; /** * Removes a session value for a given key. * * @param string $key */ public function remove(string $key): void; /** * Checks if the session has a value for the given key. * * @param string $key * * @return bool */ public function has(string $key): bool; /** * Clears all session data and generates a new internal session identifier. */ public function destroy(): void; /** * Renew the current session by generating a new internal session identifier. */ public function regenerateId(): void; /** * Returns all session data as an associative array. * * @return array */ public function getAll(): array; }

To those who commented with "we don't need this", I would disagree - I think there are clear cut use cases for this, starting with stateful handlers or middlewares, in particular things like routers or controller abstractions that need to store state between requests. I think it's a good idea to have a standard way to do this that is compatible with PSR-7/15.

Further more, as Amanda explained, we need this because there is no obvious way to use sessions in a PSR-7/15 context. Using $_SESSION creates serious problems with testing, and PSR standards do not provide any alternative. This is a problem that needs to be solved.

I would point out that a session abstraction doesn't need to cover every imaginable use case - and doesn't need to have full parity with every existing framework or library out there, and and it should not aim to be a replacement for session abstractions in existing frameworks.

Looking at some of the available libraries for session management, interfaces like these should work fine (via adapters) for e.g. all of the following:

• https://github.com/psr7-sessions/storageless/blob/9.2.x/src/Storageless/Session/SessionInterface.php
• https://github.com/yiisoft/session/blob/master/src/SessionInterface.php
• https://github.com/mezzio/mezzio-session/blob/1.15.x/src/SessionInterface.php

These libraries aim to replace $_SESSION with a more testable and flexible alternative, and I think it's important to have an interface that decouples frameworks, middleware, routers, etc. from the implementation - enabling the use of session state without having to depend on a specific library.

Amanda, if you're still interested, I'd be happy to join a working group and help out. :-)