Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[Security] Make stateful firewalls turn responses private only when needed#33663
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
c8a4fef to26d15bcComparenicolas-grekas commentedSep 23, 2019 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
PR ready. I verified locally that |
26d15bc toba290eeCompareUh oh!
There was an error while loading.Please reload this page.
ba290ee to998c066Compare998c066 to20df3a1Comparefabpot commentedSep 24, 2019
Thank you@nicolas-grekas. |
…ate only when needed (nicolas-grekas)This PR was merged into the 4.4 branch.Discussion----------[Security] Make stateful firewalls turn responses private only when needed| Q | A| ------------- | ---| Branch? | 4.4| Bug fix? | no| New feature? | yes| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets |#26769 *et al.*| License | MIT| Doc PR | -Replaces#28089By taking over session usage tracking and replacing it with token usage tracking, we can prevent responses that don't actually use the token from turning responses private without changing anything to the lifecycle of security listeners. This makes the behavior much more seamless, allowing to still log the user with the monolog processor, and display it in the profiler toolbar.This works by using two separate token storage services:- `security.token_storage` now tracks access to the token and increments the session usage tracker when needed. This is the service that is injected in userland.- `security.untracked_token_storage` is a raw token storage that just stores the token and is disconnected from the session. This service is injected in places where reading the session doesn't impact the generated output in any way (as e.g. in Monolog processors, etc.)Commits-------20df3a1 [Security] Make stateful firewalls turn responses private only when needed
…colas-grekas)This PR was merged into the 4.4 branch.Discussion----------[Security] add "anonymous: lazy" mode to firewalls| Q | A| ------------- | ---| Branch? | 4.4| Bug fix? | no| New feature? | yes| Deprecations? | no| Tickets |Fixes#26769 et al.| License | MIT| Doc PR | -Contains#33663 until it is merged.This PR allows defining a firewall as such:```yamlsecurity: firewalls: main: anonymous: lazy```This means that the corresponding area should not start the session / load the user unless the application actively gets access to it. On pages that don't fetch the user at all, this means the session is not started, which means the corresponding token neither is. Lazily, when the user is accessed, e.g. via a call to `is_granted()`, the user is loaded, starting the session if needed.See#27817 for previous explanations on the topic also.Note that thanks to the logic in#33633, this PR doesn't have the drawback spotted in#27817: here, the profiler works as expected.Recipe update pending atsymfony/recipes#649Commits-------5cd1d7b [Security] add "anonymous: lazy" mode to firewalls
Toflar commentedNov 27, 2019
I don't quite get all the details that were discussed here and in the APIP issue (#34220) but this is really breaking the current caching implementation for Contao. We're using |
nicolas-grekas commentedNov 27, 2019
Even when there is no token, the page cannot be cached. Why? Because if you cache it, it means you're going to serve a response from the cache that has been generated while no token was set - while the content of the resource could be different when there is a token. Seehttps://symfony.com/blog/new-in-symfony-4-4-lazy-firewalls for a new feature in 4.4 that improves the situation. |
Toflar commentedNov 28, 2019
I agree. However, that's kind of killing our concept. I'm fine with it in Symfony though, as it seems to make sense for the majority of apps. We have the option to disable the auto control by setting the header on the response. However, I would still like to be able to track whether a session has been used or not - independent from
That's unrelated. A |
Uh oh!
There was an error while loading.Please reload this page.
Replaces#28089
By taking over session usage tracking and replacing it with token usage tracking, we can prevent responses that don't actually use the token from turning responses private without changing anything to the lifecycle of security listeners. This makes the behavior much more seamless, allowing to still log the user with the monolog processor, and display it in the profiler toolbar.
This works by using two separate token storage services:
security.token_storagenow tracks access to the token and increments the session usage tracker when needed. This is the service that is injected in userland.security.untracked_token_storageis a raw token storage that just stores the token and is disconnected from the session. This service is injected in places where reading the session doesn't impact the generated output in any way (as e.g. in Monolog processors, etc.)