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
This PR was merged into the 3.4 branch.
Discussion
----------
[PhpUnitBridge] Remove use of ForwardCompatTrait
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #32844
| License | MIT
| Doc PR | NA
With #32882 the ForwardCompatibilityTrait is injected in TestCase which now act as a true polyfill
Commits
-------
ac6242f36b Remove use of ForwardCompatTrait
This PR was merged into the 3.4 branch.
Discussion
----------
Remove dead tests fixtures
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Once this is merged up to 4.2, I will check 4.2.
Commits
-------
f7e24c2c80 Remove dead tests fixtures
Keep to use the same CS in all the Symfony code base.
Use:
```php
$resolver->setDefaults([
'compound' => false
]);
```
Instead of:
```php
$resolver->setDefaults(
[
'compound' => false,
]
);
```
Keep the double split when the method has two or more arguments.
I miss a PSR with this rule.
Some attributes being used in the phpunit configuration files, namely
failOnRisky and failOnWarning were introduced in phpunit 5.2.0. The
Composer configuration shows that tests should run with old versions of
phpunit, but phpunit only validates the configuration against the XSD
since phpunit 7.2.0.
These changes can be tested as follows:
wget http://schema.phpunit.de/5.2/phpunit.xsd
xargs xmllint --schema phpunit.xsd 1>/dev/null
find src -name phpunit.xml.dist| xargs xmllint --schema phpunit.xsd 1>/dev/null
See 7e06a82806
See 46e3745a03/composer.json (L98)
* 2.8:
[php_cs] disable fopen_flags
[CS] Remove unused variables passed to closures
[CS] Remove empty comment
[CS] Enforces null type hint on last position in phpDocs
[CS] Use combined assignment operators when possible
Fix a typo in error messages
[Console] Add missing null to input values allowed types
[PHPUnitBridge] Fix microtime() format
bumped Symfony version to 2.8.47
update CONTRIBUTORS for 2.8.46
updated VERSION for 2.8.46
updated CHANGELOG for 2.8.46
* 2.8:
Fix CS
Allow reuse of Session between requests
Provide debug_backtrace with proper args
forward false label option to nested types
forward the invalid_message option in date types
* 2.8:
Fix Clidumper tests
Enable the fixer enforcing fully-qualified calls for compiler-optimized functions
Apply fixers
Disable the native_constant_invocation fixer until it can be scoped
Update the list of excluded files for the CS fixer
