* 5.2:
Added additional file existence check on temporary file cleanup for dumpFile method
fix lexing inline sequences/mappings with trailing whitespaces
Added test for issue 39229
Bump Symfony version to 5.2.1
Update VERSION for 5.2.0
Update CHANGELOG for 5.2.0
[Security] [DX] Automatically add PasswordUpgradeBadge + default support() impl in AbstractFormLoginAuthenticator
[Console] Enable hyperlinks in Konsole/Yakuake
* 5.1:
Added additional file existence check on temporary file cleanup for dumpFile method
fix lexing inline sequences/mappings with trailing whitespaces
Added test for issue 39229
[Console] Enable hyperlinks in Konsole/Yakuake
* 4.4:
Added additional file existence check on temporary file cleanup for dumpFile method
fix lexing inline sequences/mappings with trailing whitespaces
Added test for issue 39229
[Console] Enable hyperlinks in Konsole/Yakuake
This PR was merged into the 4.4 branch.
Discussion
----------
[Console] Re-enable hyperlinks in Konsole/Yakuake
| Q | A
| ------------- | ---
| Branch? | 4.4 <!-- see below -->
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | Fix#31809 <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
Hyperlinks feature was broken in KDE's Konsole/Yakuake (#31809) and thus disabled by #31849.
But the feature has been recently [implemented](https://invent.kde.org/utilities/konsole/-/merge_requests/138), and is about to be released in KDE 20.12 on December 10th 2020, see [release notes](https://community.kde.org/Releases/20.12_Release_Notes#Konsole).
Tested in RC version and seems to be working fine. The feature is disabled by default (as per security concerns), but even when disabled, it just gracefully don't show the links.
Commits
-------
728edf36bf [Console] Enable hyperlinks in Konsole/Yakuake
This PR was squashed before being merged into the 5.2 branch.
Discussion
----------
[Security] [DX] Automatically add PasswordUpgradeBadge + default support() impl in AbstractFormLoginAuthenticator
| Q | A
| ------------- | ---
| Branch? | 5.2 (hopefully? sorry to keep pushing the barrier here)
| Bug fix? | no
| New feature? | yes (sort of)
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
These are 2 suggestions we found while implementing `make:auth` for the new system (https://github.com/symfony/maker-bundle/pull/736):
Impact on a custom login form authenticator ([as generated by the new maker](https://github.com/symfony/maker-bundle/pull/736/files#diff-528164b6c24778d5e81fa3819b0552f0e68a9fea33c7d3446a012f3da7d0af60)):
* **Automatically add `PasswordUpgradeBadge`** if there is a user password with valid password credentials.
```diff
// ...
return new Passport(
new UserBadge($userIdentifier),
new PasswordCredentials($password),
[
- new PasswordUpgradeBadge($password),
new CsrfTokenBadge('authenticate', $csrf),
]
)
```
Note that this does not automatically migrate all passwords: it still relies on `PasswordUpgraderInterface` to be implemented on the user loader/provider.
* **Add default implementation of `AbstractFormLoginAuthenticator::support()`**
```diff
- public function supports(Request $request): ?bool
- {
- return self::LOGIN_ROUTE === $request->attributes->get('_route')
- && $request->isMethod('POST');
- }
```
cc @weaverryan @jrushlow
Commits
-------
27450c0bb4 [Security] [DX] Automatically add PasswordUpgradeBadge + default support() impl in AbstractFormLoginAuthenticator
Add logic for locking row for update when the doctrine dbal connection is sqlsrv. This is a quick and dirty solution, but it prevents the need to rewrite the logic due to doctrine dbal limitations.
See issue https://github.com/symfony/symfony/issues/39117
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[DependencyInjection] Fix circular in DI with lazy + byContruct loop
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#39120
| License | MIT
| Doc PR | -
This fix another issue lazy service.
It partially revert #38980 and #39021
Initially, we trusted lazy services to be lazy and not beeing called while building the services graph
=> bug #38970 when lazy deps is injected in a factory, it may be consumed directly to build the object before the graph is fully built
Fixed by #38980 => lazy service are considered as "normal service"
=> bug #39015 some loop are not resolvable with "normal service", but it shouldn't be an issue when servie proxifyied
Fixed by #39021 => lazy service are considered as "normal service" except when proxyfied
=> bug #39120 some loop are not resolvable with "normal service", but it shouldn't be an issue because the lazy service is injected in the constructor and user
Fixed by this PR => that revert to the initial state. lazy service are trusted.
But now, The IterratorArgument injected in a factory (single exception) is not more considered as lazy
Commits
-------
54af139a4e [DependencyInjection] Fix circular in DI with lazy + byContruct loop
This PR was squashed before being merged into the 5.2 branch.
Discussion
----------
[Security] Automatically register custom authenticator as entry_point (if supported)
| Q | A
| ------------- | ---
| Branch? | 5.2 (hopefully?)
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix#37068
| License | MIT
| Doc PR | -
@weaverryan came up with exactly the same issue as proposed by a contributor before (see referenced ticket). Back then, it was decided impossible to fix: see https://github.com/symfony/symfony/pull/37075. However, after some thinking we came up with a way to fix the issue and improve the DX for custom authenticators.
The new authenticators are no longer required to implement `AuthenticationEntryPointInterface` (required for internal authenticators like the `RememberMeAuthenticator` and pre authenticated ones). This PR uses a compiler pass to check if a custom authenticator is supported:
```yaml
security:
firewalls:
main:
# in any case, if an entry_point is already configured it'll not be overriden
# (http_basic remains the entry point here)
http_basic: ~
custom_authenticator: App\Security\CustomAuthenticator
entry_point: http_basic
# if only one custom authenticator implements AuthenticationEntryPointInterface,
# it's automatically configured as the entry point
custom_authenticator: App\Security\CustomAuthenticator
custom_authenticators: [App\Security\CustomAuthenticator, App\Security\NoEntryPointAuthenticator]
# if no custom authenticator implements AuthenticationEntryPointInterface,
# an error is thrown
custom_authenticator: App\Security\NoEntryPointAuthenticator
# if more than one authenticator implements AuthenticationEntryPointInterface,
# the entry point must be configured explicitly (or an error is thrown)
custom_authenticators: [App\Security\CustomAuthenticator, App\Security\AnotherCustomAuthenticator]
entry_point: App\Security\CustomAuthenticator
```
---
I know this is very late for Symfony 5.2. It would be good to decide whether this can be included in the release, in order to smooth out the biggest struggle for people using custom authenticators for the first time.
Commits
-------
cab0672248 [Security] Automatically register custom authenticator as entry_point (if supported)
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
Add Romanian missing translations
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | kinda
| New feature? | no
| Deprecations? | no
| Tickets | Fix#38758
| License | MIT
| Doc PR | n/a
Commits
-------
6aa31a13c7 Add Romanian missing translations
