-
-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hi there! I have a similar library. #3
Comments
I created this issue when the repo belonged to Matthew. So, anyone who is confused by the usage of "you", it's Matthew. Originally posted by @ojhaujjwal at zendframework/zend-expressive-session#1 (comment) |
No reply :/ Originally posted by @ojhaujjwal at zendframework/zend-expressive-session#1 (comment) |
We released 0.1, not 1.0; we expect we may still make changes to the API. I recall looking through your library, and thought I'd responded; I'll check later to see if I can find my notes. Originally posted by @weierophinney at zendframework/zend-expressive-session#1 (comment) |
First, I see a number of similarities in what we're doing. For instance:
There are a few key differences. First, we only pass the session itself as a request attribute, not the "manager" or "persistence". We feel that users generally should not work directly with these aspects, as they can lead to potentially conflicting state and/or overwriting. Second, and related, we handle regeneration as a flag + persistence operation, vs. solely as a "manager" operation. This is done to ensure multiple regenerations are not invoked, potentially leading to conflicting session cookies. This also allows us to bind a single Third, we merge the "manager" and "handler" responsibilities into a single interface, with only two responsibilities: initializing the session, and persisting it. This approach essentially allows us to be flexible in what we consider "persistence". For instance, with JWT, you would not actually "persist" anything; instead, you parse incoming data from a cookie, and send session data to the user via a response cookie, never storing anything within any application persistence layers. With our proposed interface, this becomes a first-class approach to how sessions are implemented, vs something that has to be coded separately. It also opens the possibility of other approaches we haven't thought up yet! All things told, I think our two approaches are fairly compatible. There are just a few key design decisions between how we each approach persistence (ext-session-influenced, vs. open-ended). Originally posted by @weierophinney at zendframework/zend-expressive-session#1 (comment) |
thanks for the perfect explanation. the issue can be closed. |
Hey. I have followed you on Github and, today, I noticed that you were working on this repo.
I had worked on somewhat similar library a few months back. It's called ps7-session.
It is not completely dependent on expressive. It's a php7 based session library with added support for interop middleware-based applications. Check this
I was wondering if we could talk about whether these two could complement each other. If using that library as a dependency is a good idea. I am open to moving it to zend organization if it's good enough for you people :D
Or, maybe, this library can take some ideas from my library.
The reason I created that library because I was trying to run an expressive based application with reactphp/http and
$_SESSION
was not usable. Running the expressive application with reactphp was actually experimental and won't make it to production(atleast for now). But, on the process, I was motivated enough to write that library.Best Regards,
Your long-time fan and follower,
Ujjwal Ojha
Originally posted by @ojhaujjwal at zendframework/zend-expressive-session#1
The text was updated successfully, but these errors were encountered: