[Security] Session concurrency control #12810
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
There was a problem hiding this comment.
This does only belong to your other pull request, doesn't it?
Contributor
Author
There was a problem hiding this comment.
Yes, this PR includes the other PR first two changesets.
Member
|
Closing this stale PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR allow you to control concurrent sessions. You can choose if you want to block new sessions or expire the oldest ones in order to limit the number of active sessions per user. To limit the access from expired sessions, this PR depends on the new firewall introduced in #12807.
To expire the oldest sessions, is necessary to access to the other sessions information from the current request, so a
SessionRegistryis used to store this info. This service relies on a session storage service (SessionRegistryStorageInterface) to persist the info. Currently only a filesystem based implementation is provided; a Doctrine based one could be added to the Doctrine Bridge as I did in my previous #12009 PR.As it occurs with the sessions, the information stored in the registry, should be periodically removed. Currently, I've implemented an event listener that will be called with the same probability that the native session garbage collector, but any better solution to sync garbage collection for native sessions and registry info is welcome.