-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[SecurityBundle] Fix FirewallConfig nullable arguments #20589
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
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.
It's indeed a strange behavior to get empty strings for "abstract" arguments by default, having null instead would be logic imho.
👍 For fixing this on 3.2. Thanks @ogizanagi
Status: reviewed |
Nullable arguments were replaced by empty string by the DIC config if values weren't replaced in the extension.
@chalasr the issue is that |
@stof : That's another issue, but do you know why we can't infer |
yeah, changing it is impossible for BC anyway |
👍, must be on 3.2 (BC break otherwise, because argument reordering) |
@nicolas-grekas : I've removed the deprecation as well as asked in #20591 (comment) |
Thank you @ogizanagi. |
…izanagi) This PR was squashed before being merged into the 3.2 branch (closes #20589). Discussion ---------- [SecurityBundle] Fix FirewallConfig nullable arguments | Q | A | ------------- | --- | Branch? | 3.2 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no, but removes one | Tests pass? | yes | Fixed tickets | N/A | License | MIT | Doc PR | N/A Nullable arguments were replaced by empty strings by the DIC config if values weren't replaced in the extension. Another solution (looking safer to me) is to apply the following changes in the DIC configuration: ```diff diff --git a/src/Symfony/Bundle/SecurityBundle/Resources/config/security.xml b/src/Symfony/Bundle/SecurityBundle/Resources/config/security.xml index 54e5734..499dd5e 100644 --- a/src/Symfony/Bundle/SecurityBundle/Resources/config/security.xml +++ b/src/Symfony/Bundle/SecurityBundle/Resources/config/security.xml @@ -116,15 +116,15 @@ <service id="security.firewall.config" class="Symfony\Bundle\SecurityBundle\Security\FirewallConfig" abstract="true" public="false"> <argument /> <!-- name --> - <argument /> <!-- user_checker --> - <argument /> <!-- request_matcher --> - <argument /> <!-- security enabled --> - <argument /> <!-- stateless --> - <argument /> <!-- provider --> - <argument /> <!-- context --> - <argument /> <!-- entry_point --> - <argument /> <!-- access_denied_handler --> - <argument /> <!-- access_denied_url --> + <argument>null</argument> <!-- user_checker --> + <argument>null</argument> <!-- request_matcher --> + <argument>true</argument> <!-- security enabled --> + <argument>false</argument> <!-- stateless --> + <argument>null</argument> <!-- provider --> + <argument>null</argument> <!-- context --> + <argument>null</argument> <!-- entry_point --> + <argument>null</argument> <!-- access_denied_handler --> + <argument>null</argument> <!-- access_denied_url --> <argument type="collection" /> <!-- listeners --> </service> ``` But it doesn't seem to be the way we deal with arguments meant to be replaced by extensions in the Symfony core. cc @chalasr This PR also removes the FirewallContext mandatory `FirewallConfig` argument deprecation for reasons expressed in #20591 (comment) Commits ------- 79ef474 [SecurityBundle] Remove FirewallContext mandatory FirewallConfig argument deprecation f09ccf4 [SecurityBundle] Fix FirewallConfig nullable arguments
Nullable arguments were replaced by empty strings by the DIC config if values weren't replaced in the extension.
Another solution (looking safer to me) is to apply the following changes in the DIC configuration:
But it doesn't seem to be the way we deal with arguments meant to be replaced by extensions in the Symfony core.
cc @chalasr
This PR also removes the FirewallContext mandatory
FirewallConfig
argument deprecation for reasons expressed in #20591 (comment)