This PR was merged into the 5.2 branch.
Discussion
----------
[Security] Fix event propagation for AuthenticationTokenCreatedEvent when globally registered
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| License | MIT
As promised, here's the follow-up to #39621, fixing `AuthenticationTokenCreatedEvent` to be propated from the global event dispatcher to firewall-specific event dispatchers.
The event was added in Symfony 5.2, therefore the separate PR targeting the 5.2 branch.
Commits
-------
68aaf4f916 Add AuthenticationTokenCreatedEvent to be propagated
This PR was merged into the 5.2 branch.
Discussion
----------
[Validator] Update Isin message to match the translation files
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#39645
| License | MIT
| Doc PR | N/A
Commits
-------
add3cdd623 [Validator] Update Isin message to match the translation files.
This PR was submitted for the 5.x branch but it was merged into the 4.4 branch instead.
Discussion
----------
Update README.md
update readme semver link to use https
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | no
| License | MIT
| Doc PR | no
I just update semver link to use https instead of http. 😉
Commits
-------
9ee2dc6d66 Update README.md
This PR was merged into the 4.4 branch.
Discussion
----------
[Messenger] Fix stopwach usage if it has been reset
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
I'm slowly migrating an application to messenger (from swarrot) and I
hit a strange bug. My message was well processeed **BUT** retry!
It comes from two things
* I manually reset the application (via the service resetter, to keep a
low memory usage)
* symfony/messenger try to collect some information, but since the
stopwatch has been reset, an exception occurs and the message has been
retried
So this patch avoid throwing an exception when everything works well
<details>
<summary>the trace:</summary>
```
18:45:41 INFO [messenger] Message AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage handled by AppBundle\Crawler\Messenger\MessageHandler\CrawlSitemapMessageHa
ndler::__invoke
[
"message" => AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage^ {
-crawlId: "885d23a7-8ad5-4935-a2b3-1c114ac76ded"
},
"class" => "AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage",
"handler" => "AppBundle\Crawler\Messenger\MessageHandler\CrawlSitemapMessageHandler::__invoke"
]
18:45:41 ERROR [messenger] Error thrown while handling message AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage. Sending for retry #1 using 1000 ms delay. Erro
r: "Event ""Symfony\Component\Messenger\Middleware\HandleMessageMiddleware" on "messenger.bus.default"" is not started."
[
"message" => AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage^ {
-crawlId: "885d23a7-8ad5-4935-a2b3-1c114ac76ded"
},
"class" => "AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage",
"retryCount" => 1,
"delay" => 1000,
"error" => "Event ""Symfony\Component\Messenger\Middleware\HandleMessageMiddleware" on "messenger.bus.default"" is not started.",
"exception" => LogicException {
#message: "Event ""Symfony\Component\Messenger\Middleware\HandleMessageMiddleware" on "messenger.bus.default"" is not started."
#code: 0
#file: "./vendor/symfony/symfony/src/Symfony/Component/Stopwatch/Section.php"
#line: 142
trace: {
./vendor/symfony/symfony/src/Symfony/Component/Stopwatch/Section.php:142 { …}
./vendor/symfony/symfony/src/Symfony/Component/Stopwatch/Stopwatch.php:126 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/TraceableMiddleware.php:75 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/HandleMessageMiddleware.php:83 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/SendMessageMiddleware.php:74 { …}
./src/Middleware/ResetApplicationMiddlerwareMiddleware.php:14 {
AppBundle\Middleware\ResetApplicationMiddlerwareMiddleware->handle(Envelope $envelope, StackInterface $stack): Envelope^
› echo "couocu";
› return $stack->next()->handle($envelope, $stack);
› }
}
./vendor/symfony/symfony/src/Symfony/Bridge/Doctrine/Messenger/DoctrinePingConnectionMiddleware.php:34 { …}
./vendor/symfony/symfony/src/Symfony/Bridge/Doctrine/Messenger/AbstractDoctrineMiddleware.php:45 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/FailedMessageProcessingMiddleware.php:34 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/DispatchAfterCurrentBusMiddleware.php:68 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/RejectRedeliveredMessageMiddleware.php:48 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/AddBusNameStampMiddleware.php:37 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/TraceableMiddleware.php:43 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/MessageBus.php:80 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/TraceableMessageBus.php:41 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/RoutableMessageBus.php:54 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Worker.php:114 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Worker.php:77 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Command/ConsumeMessagesCommand.php:198 { …}
./vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:255 { …}
./vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:989 { …}
./vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:96 { …}
./vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:290 { …}
./vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:82 { …}
./vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:166 { …}
./bin/console:29 { …}
}
}
]
```
</details>
Commits
-------
bf4b0cc022 [Messenger] Fix stopwach usage if it has been reset
This PR was merged into the 5.1 branch.
Discussion
----------
[Uid] Handle ValueErrors triggered by ext-uuid on PHP 8
| Q | A
| ------------- | ---
| Branch? | 5.1
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
Follows symfony/polyfill#318.
On PHP 8, the UUID extension triggers `ValueErrors` if we pass an invalid UUID to one of the `uuid_*` functions. This PR handles those errors so that the component behaves the same on PHP 7 and 8.
Commits
-------
5305170e54 Handle ValueErrors triggered by ext-uuid on PHP 8
This PR was squashed before being merged into the 5.2 branch.
Discussion
----------
[FrameworkBundle][RateLimiter] Update typos in config
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
This is just a super minor
Commits
-------
1b4ab3e3a2 [FrameworkBundle][RateLimiter] Update typos in config
This PR was merged into the 5.1 branch.
Discussion
----------
[Security] Add test to ensure all security events are propagated
| Q | A
| ------------- | ---
| Branch? | 5.1
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| License | MIT
Follow-up to #39621. As requested by @wouterj I'm adding a dedicated test case to ensure the security events are propagated from global to firewall-level event dispatcher.
I'll file another PR to add `AuthenticationTokenCreatedEvent` as soon as this has been merged and copied to the 5.2 branch, that I need to target for the `AuthenticationTokenCreatedEvent` change.
Happy holidays!
Commits
-------
e78adf7604 Add test case to ensure all security events are propagated
This PR was merged into the 4.4 branch.
Discussion
----------
CS: Apply ternary_to_null_coalescing fixer
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
Since we don't need to support PHP 5 anymore, we can upgrade our older code to use the null coalescing operator and enforce its usage through our PHP CS Fixer configuration. I think, the usage of that operator improves the readability of our codebase at lot.
Note that the changes in this PR are (with the exception of `.php_cs.dist`) completely automated. You should get the same results by running the following command (and reverting the changes to PhpUnitBridge afterwards).
```sh
php-cs-fixer fix --rules='{"ternary_to_null_coalescing":true}' src
```
Commits
-------
07c4773d98 CS: Apply ternary_to_null_coalescing fixer
This PR was merged into the 4.4 branch.
Discussion
----------
[Mailer] Handle failure when sending DATA
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
When an exception is thrown while sending an email via SMTP (ie. A attachment is not readable) the SMTP connection is left opened with a partial message sent.
This PR closes the connection (we can't abort after sending the `DATA` command) in such situation.
/cc @fabpot
Commits
-------
849211a780 Handle failure when sending DATA
This PR was squashed before being merged into the 5.1 branch.
Discussion
----------
[Security] Fix event propagation for globally registered security events
| Q | A
| ------------- | ---
| Branch? | 5.1
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| License | MIT
When new authenticator security is enabled, the `AuthenticatorManager` is using its own firewall-specific event dispatcher. To allow security events being listened to on the global level, `RegisterGlobalSecurityEventListenersPass` is there to automatically add globally registered event listeners to the firewall-specific event dispatchers.
`RegisterGlobalSecurityEventListenersPass` contains a list of events that are propagated, but unfortunately this list is incomplete as there are other events in `AuthenticatorManager` that would need too be propagated. So I added the missing (older) security events. These older events may also be registered by their name, rather than the FQN of the class, so I've also added those.
As this is targeting 5.1, I'll file another PR for the `AuthenticationTokenCreatedEvent` that was introduced in 5.2, as soon as this change was merged into 5.x.
On a note, I feel this "whitelist" approach to propagate security events to the global dispatcher isn't that great, because it's prone to error. Additional security events may be added in the future and adding these to `RegisterGlobalSecurityEventListenersPass` can easily be missed. When I added `AuthenticationTokenCreatedEvent` in PR #37359 I wasn't aware of this propagation mechanic existed and also no one reviewing the PR noticed it.
Additional changes:
- Typo fix :)
- The `array_uintersect` in `RegisterGlobalSecurityEventListenersPassTest` wasn't implemented correctly *
\* That function's behavior is really odd and easy to be used in the wrong way. The callback function isn't intended to return true/false for matching items, but return -1/0/1 like sorting functions. The tests seemingly only worked by chance as returning true/false is doing pretty much the opposite of what the callback function is supposed to do.
Commits
-------
1675864032 [Security] Fix event propagation for globally registered security events
This PR was merged into the 5.2 branch.
Discussion
----------
[TwigBridge] allow null values in form helpers
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix #39591| License | MIT
| Doc PR |
Commits
-------
f908047c6b allow null values in form helpers
This PR was merged into the 4.4 branch.
Discussion
----------
[ProxyManagerBridge] fix PHP notice, switch to "friendsofphp/proxy-manager-lts"
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#39089
| License | MIT
| Doc PR | -
I submitted the fix for #39089 on the origin library at https://github.com/Ocramius/ProxyManager/pull/646.
Because of the [versioning policy](6d45615155/version-support.md (dependency-upgrades)) in use at the origin library, this fix won't be available for PHP < 7.4.
We usually resort to monkey-patching to workaround the policy and still ship the fix for 4.4 (which supports PHP >= 7.1).
This time, and as explained in https://github.com/Ocramius/ProxyManager/issues/630, I propose to delegate the fix to [friendsofphp/proxy-manager-lts](https://github.com/FriendsOfPHP/proxy-manager-lts/). It already embeds the fix and a few others that allow us to remove most of the monkey-patching we had to accumulate over time.
Commits
-------
389f5304c7 [ProxyManagerBridge] fix PHP notice, switch to "friendsofphp/proxy-manager-lts"
This PR was merged into the 5.2 branch.
Discussion
----------
[Security] Add RememberMe Badge to LoginLinkAuthenticator
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
I'm replacing a custom home-made magic link authenticator by the Symfony one, and I missed this behavior. I had to use a EventListener to add the badge to the passeport.
I'm not sure, if the badge were missing on purpose /cc @weaverryan @wouterj
Commits
-------
d38fc4d678 Add RememberMe Badge to LoginLinkAuthenticator
