Adding PSR6 session handler #23321
Adding PSR6 session handler #23321
Conversation
|
New features should not go in master but in 3.4. I'm not sure about this one. Non-locking session handlers generally cause WTF issues (people wondering why their session disappear when doing AJAX requests). Do we actually want to add one more ? |
Thank you. I've updated this.
What do you propose? This handler suffers from the same issues as existing ones. |
|
I proposed this in the past and @nicolas-grekas gave some good arguments on why this may not be the best idea (see #19193 (comment)). |
|
I guess I should have made a better search before I wrote this PR. I know a cache is not a data store and I know that PSR-6 is for caching and a SessionHandler needs a data store. But using the abstraction over different storages that PSR-6 provide is excellent. Then we can leave it for the user to not use the As an alternative to this Handler, we should use Memcache, Memcached, Redis, Predis, (MongoDB, Pdo etc) etc. The end result would be the same. We would still use a cache storage but without the PSR6 abstraction. |
|
👎 for the same reasons as previously. Although technically PSR6 may fit the very simple case, it's a dead end in terms of feature for the session domain. No locking, and no possibility for more advanced sessions related features. |
That makes the difference for me. I'll look into if we can do anything good with the session. Because I really think there should be core support for storing sessions in Memcache and Redis. Thank you for the reviews. |
It is very common that you store your session in Memcached or Redis. But instead of creating a RedisHandler we should be more abstract and go with a PSR6 handler. That will give the flexibility to use any storage.
This PR could deprecate the Memcached, Memcache, MongoDB handlers.. But I left that decision to a separate PR.