Skip to content

[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

Merged
merged 2 commits into from
Nov 24, 2016
Merged

[SecurityBundle] Fix FirewallConfig nullable arguments #20589

merged 2 commits into from
Nov 24, 2016

Conversation

ogizanagi
Copy link
Contributor

@ogizanagi ogizanagi commented Nov 22, 2016

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 --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)

@ogizanagi ogizanagi changed the title [SecurityBundle] Fix nullable arguments [SecurityBundle] Fix FirewallConfig nullable arguments Nov 22, 2016
@ogizanagi ogizanagi changed the base branch from master to 3.2 November 22, 2016 09:39
Copy link
Member

@chalasr chalasr left a 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

@chalasr
Copy link
Member

chalasr commented Nov 22, 2016

Status: reviewed

Nullable arguments were replaced by empty string by the DIC config if values weren't replaced in the extension.
@stof
Copy link
Member

stof commented Nov 22, 2016

@chalasr the issue is that <argument /> and <argument></argument> are exactly the same for our loader. We have no way to know how it was written before the XML parsing (as PHP is doing the XML parsing). And so it must be transformed to the empty string, not to null otherwise it becomes impossible to specify the empty string in XML config files

@ogizanagi
Copy link
Contributor Author

@stof : That's another issue, but do you know why we can't infer null from <argument /> whereas <argument type="string"/> would allow to specify it should be an empty string? BC reasons?

@stof
Copy link
Member

stof commented Nov 22, 2016

yeah, changing it is impossible for BC anyway

@nicolas-grekas
Copy link
Member

👍, must be on 3.2 (BC break otherwise, because argument reordering)

@ogizanagi
Copy link
Contributor Author

@nicolas-grekas : I've removed the deprecation as well as asked in #20591 (comment)

@fabpot
Copy link
Member

fabpot commented Nov 24, 2016

Thank you @ogizanagi.

@fabpot fabpot merged commit 79ef474 into symfony:3.2 Nov 24, 2016
fabpot added a commit that referenced this pull request Nov 24, 2016
…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
@ogizanagi ogizanagi deleted the fix/firewall_config_nullables branch November 24, 2016 06:55
@fabpot fabpot mentioned this pull request Nov 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants