-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[HttpFoundation] add a handler to store sessions in a PSR-6 cache #19193
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
Conversation
public function open($savePath, $sessionId) | ||
{ | ||
try { | ||
$this->cachePool->getItem($sessionId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure if this is necessary. this mean every session reads the cache twice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's debatable. I am not sure either. The thing is that read()
cannot indicate that it failed. Another possible solution is to keep the read cache item in memory here and thus be able to avoid the second call to getItem()
in read()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean it can only fail for invalid session id chars. And since there is no fallback solution like encoding chars, I don't see the point of indicating failure. So it would be the same as non-existing session.
The design of a cache pool makes it extremely unreliable for session handling to me. Think of error handling: psr-6 explicitly says that "false" is the only way to report errors. 👎 |
@nicolas-grekas We already have handlers for Memcache(d) and there are other implementations outside the core too (for example, for Redis). And as long as you make sure that you do not flush the cache when not needed this works as expected. |
What's the purpose of this adapter? We're perfectly able to provide native handler that fit the session domain. I see the domain mismatch, but I don't see the benefit that overcomes this issue. |
Currently, we ship a set of specific session storage handlers with the HttpFoundation aimed to support different storage backends. I suggest to add a new handler that is capable to work with an arbitrary PSR-6 cache item pool to be able to use other backends currently not supported by the core.