This repository has been archived on 2023-08-20. You can view files and clone it, but cannot push or open issues or pull requests.
Go to file
Robin Chalas 2ecd7936b1 bug #34080 [SecurityBundle] correct types for default arguments for firewall configs (shieldo)
This PR was merged into the 3.4 branch.

Discussion
----------

[SecurityBundle] correct types for default arguments for firewall configs

| Q             | A
| ------------- | ---
| Branch?       | 3.4 (and forward)
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | n/a
| License       | MIT
| Doc PR        | n/a

Up until now, the default template arguments in the `security.firewall.config` abstract service definition have been each defined (aside from the argument for `$listeners` which is given a `collection` type) in the XML as

```xml
<argument />
```

which resolves to an empty string, despite that some of the arguments are typed to being either `bool` or `array|null` on the `Symfony\Bundle\SecurityBundle\Security\FirewallConfig` class itself.

This wouldn't be so much of a problem if the child definitions that use this as a template overrode all the arguments every time, but in the case of firewall configs that mark security as _not_ being enabled, [only the first few arguments are overwritten](https://github.com/symfony/symfony/blob/3.4/src/Symfony/Bundle/SecurityBundle/DependencyInjection/SecurityExtension.php#L349-L352), so firewall config objects that do not have security enabled are instantiated by the DI container with parameters with some of the wrong types.

In general this wouldn't be an issue, as firewalls with security not enabled would not usually be consumed in a context where further security-related config were needed, but there is a case in `Symfony\Bundle\SecurityBundle\DataCollector\SecurityDataCollector` where the method `getSwitchUser()` on the firewall config object [can be called](https://github.com/symfony/symfony/blob/3.4/src/Symfony/Bundle/SecurityBundle/DataCollector/SecurityDataCollector.php#L181) without checking first whether the firewall has security enabled, which leads to an exception being thrown:

```
Symfony\Component\Debug\Exception\ContextErrorException
Warning: Illegal string offset 'parameter'
in vendor/symfony/symfony/src/Symfony/Bundle/SecurityBundle/DataCollector/SecurityDataCollector.php (line 184)
```

which is down to the firewall config being set with an empty string rather than `null` (in which case the logic here would function as expected).

It seemed most appropriate as a fix (especially given possible introduction of scalar type hints in the future) to apply types to the default arguments so that it was no longer possible to instantiate a firewall config object with parameters of unexpected types.

<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.

Additionally (see https://symfony.com/roadmap):
 - Always add tests and ensure they pass.
 - Never break backward compatibility (see https://symfony.com/bc).
 - Bug fixes must be submitted against the lowest maintained branch where they apply
   (lowest branches are regularly merged to upper ones so they get the fixes too.)
 - Features and deprecations must be submitted against branch 4.4.
 - Legacy code removals go to the master branch.
-->

Commits
-------

6b7044fc01 [SecurityBundle] correct types for default arguments for firewall configs
2019-10-28 18:20:44 +01:00
.github fix paths to detect code owners 2019-10-26 10:25:32 +02:00
src/Symfony bug #34080 [SecurityBundle] correct types for default arguments for firewall configs (shieldo) 2019-10-28 18:20:44 +01:00
.appveyor.yml [CI] fix building local packages 2019-10-15 14:09:56 +02:00
.editorconfig Update .editorconfig 2018-09-06 16:22:56 +02:00
.gitignore Run the phpunit-bridge from a PR 2019-08-02 17:46:19 +02:00
.php_cs.dist Remove superfluous phpdoc tags 2019-08-14 13:59:53 +02:00
.travis.yml [CI] fix building local packages 2019-10-15 14:09:56 +02:00
CHANGELOG-3.0.md Merge branch '2.8' into 3.1 2016-08-05 10:37:39 +02:00
CHANGELOG-3.1.md updated CHANGELOG for 3.1.9 2017-01-12 12:43:31 -08:00
CHANGELOG-3.2.md use behavior instead of behaviour 2019-03-25 08:48:46 +01:00
CHANGELOG-3.3.md use behavior instead of behaviour 2019-03-25 08:48:46 +01:00
CHANGELOG-3.4.md updated CHANGELOG for 3.4.32 2019-10-07 16:41:35 +02:00
CODE_OF_CONDUCT.md Added the Code of Conduct file 2018-10-10 03:13:30 -07:00
composer.json [ProxyManager] remove ProxiedMethodReturnExpression polyfill 2019-08-29 16:54:55 +02:00
CONTRIBUTING.md Mention the community review guide 2016-12-18 22:02:35 +01:00
CONTRIBUTORS.md update CONTRIBUTORS for 3.4.32 2019-10-07 16:41:46 +02:00
LICENSE update year in license files 2019-01-01 14:45:19 +01:00
link Use the current working dir as default first arg in 'link' binary 2019-05-16 11:52:39 +02:00
phpunit sync phpunit script with master 2019-09-28 18:12:11 +02:00
phpunit.xml.dist Merge branch '2.8' into 3.4 2018-11-11 20:48:54 +01:00
README.md Merge branch '2.8' into 3.4 2018-05-25 16:50:57 +02:00
UPGRADE-3.0.md Fixed markdown file 2019-08-13 19:39:09 +02:00
UPGRADE-3.1.md [Serializer] Remove AbstractObjectNormalizer::isAttributeToNormalize 2016-12-08 16:02:32 +01:00
UPGRADE-3.2.md Merge branch '2.8' into 3.4 2018-02-22 13:28:57 +01:00
UPGRADE-3.3.md Merge branch '3.3' into 3.4 2017-11-30 15:59:23 +01:00
UPGRADE-3.4.md Merge branch '2.8' into 3.4 2018-05-31 12:13:22 +02:00
UPGRADE-4.0.md Fixed invalid VarDumper upgrade doc. 2019-10-03 11:42:21 +02:00

Symfony is a PHP framework for web applications and a set of reusable PHP components. Symfony is used by thousands of web applications (including BlaBlaCar.com and Spotify.com) and most of the popular PHP projects (including Drupal and Magento).

Installation

Documentation

Community

Contributing

Symfony is an Open Source, community-driven project with thousands of contributors. Join them contributing code or contributing documentation.

Security Issues

If you discover a security vulnerability within Symfony, please follow our disclosure procedure.

About Us

Symfony development is sponsored by SensioLabs, led by the Symfony Core Team and supported by Symfony contributors.