This PR was merged into the 3.4 branch.
Discussion
----------
[Security\Http] Prevent canceled remember-me cookie from being accepted
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35198
| License | MIT
| Doc PR | -
`RememberMeServices::autoLogin()` only checks that the cookie exists in `$request->cookies` while `loginFail()` only alter `$request->attributes` (which allows child implementations to read the canceled cookie for e.g. removing a persistent one).
This makes `autoLogin()` checks for `request->attributes` first, which fixes the linked issue.
Failure expected on deps=high build.
Commits
-------
9b711b87fe [Security] Prevent canceled remember-me cookie from being accepted
This PR was merged into the 3.4 branch.
Discussion
----------
[FrameworkBundle] Fix invalid Windows path normalization in TemplateNameParser
| Q | A
| ------------- | ---
| Branch? | 3.4 - <5.0
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | no
| License | MIT
| Doc PR | Fix invalid Windows path normalization
All versions of Symfony until 5.0 (which does no longer do extra file path normalization) normalize Windows paths wrongly.
See https://github.com/PrestaShop/PrestaShop/issues/16736 and https://bugs.php.net/bug.php?id=78939
Currently this issue can be observed when Symfony is run by NTS PHP only, but once the PHP issue will be fixed, this issue will probably affects all Windows users when absolute template name is passed to Symfony templating.
Commits
-------
130df8ca8c Fix invalid Windows path normalization
This PR was squashed before being merged into the 3.4 branch.
Discussion
----------
[FrameworkBundle] Use UserInterface to @return in getUser method
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| License | MIT
<!--
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 master.
-->
Commits
-------
9f1ebd7fb9 [FrameworkBundle] Use UserInterface to @return in getUser method
This PR was merged into the 3.4 branch.
Discussion
----------
[SecurityBundle] Properly escape regex in AddSessionDomainConstraintPass
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | https://github.com/symfony/symfony/issues/34774
| License | MIT
| Doc PR | -
`%s` should be escaped, so it is dumped as `%%s` (it ends up being properly unescaped at load time, so the passed value to the service is the same).
Commits
-------
de03cee846 [SecurityBundle] Properly escape regex in AddSessionDomainConstraintPass
This PR was merged into the 3.4 branch.
Discussion
----------
[FrameworkBundle] resolve service locators in `debug:*` commands
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#34470
| License | MIT
| Doc PR | -
Because of the way ServiceClosureArgument are dumped, we need to resolve locators after loading the xml dump of the container:
https://github.com/symfony/symfony/blob/3.4/src/Symfony/Component/DependencyInjection/Dumper/XmlDumper.php#L273
Commits
-------
820da66346 [FrameworkBundle] resolve service locators in `debug:*` commands
* Added a hardcoded day 01 in order to output the proper month November
which is the correct EOL and EOM month.
* \DateTime::createFromFormat('mY') will output December for every month
where day 31 exists.
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 prevents to exclude the RedirectController from the warmed annotation cache which would lead to warnings when trying to use the warmed cache on read only file systems
See #29357
This PR was merged into the 3.4 branch.
Discussion
----------
Fix toolbar load when GET params are present in "_wdt" route
When using a custom router that inject GET parameters, eg:
```
# services.yaml
parameters:
# Replace default url generator service
router.options.generator_base_class: Combodo\iTop\Portal\Routing\UrlGenerator
```
The path generated by the toolbar JS is HTML entity encoded which breaks the JS call (`&` becomes `&`).
| Q | A
| ------------- | ---
| Branch? | 4.4 for features / 3.4, 4.2 or 4.3 for bug fixes <!-- see below -->
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
<!--
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):
- 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
-------
5309e64949 Fix toolbar load when GET params are present in "_wdt" route
This PR was squashed before being merged into the 3.4 branch (closes#32925).
Discussion
----------
[Translation] Collect original locale in case of fallback translation
Before, it collected the fallback locale that was used to translate a key. But this information is confusing, as it does not reveal which translation key is missing in the requested language.
So I'd like to propose to track the "requested" locale instead, so that the Symfony profiler gives me the information in which locale the key is missing instead of which locale was used as a fallback.
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | yes?
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
In principle, this change is a BC break, but imho also a bug. It's really confusing when the Profiler tells you that it uses a translation fallback for an ID and locale that is actually translated. Took some debugging so recognize that this fallback came from another locale. If you think it's better to target 5.0, I'll update the PR.
Commits
-------
5564e149cb [Translation] Collect original locale in case of fallback translation
This PR was squashed before being merged into the 3.4 branch (closes#31198).
Discussion
----------
[FrameworkBundle] Fix framework bundle lock configuration not working as expected
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #31197
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/11465 & https://github.com/symfony/symfony-docs/pull/11466
This fixes#31197 and makes the lock configuration work with installations that are not full stack ones and configurations that use xml files.
Commits
-------
c7af2df340 [FrameworkBundle] Fix framework bundle lock configuration not working as expected
This PR was merged into the 3.4 branch.
Discussion
----------
fix tests depending on other components' tests
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Commits
-------
cd2f3a6056 fix tests depending on other components' tests
This PR was merged into the 3.4 branch.
Discussion
----------
Fix inconsistent return points
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #17201 in preparation for #33228
| License | MIT
| Doc PR | N/A
Inconsistent return points in methods prevent adding return types. I thought, I'll give it a try and fix them. After this PR, PhpStorm's inspection still finds 39 issues, but as far as I can tell, they're either false positives or fixture code.
Commits
-------
f5b6ee9de1 Fix inconsistent return points.
