This PR was merged into the 3.3-dev branch.
Discussion
----------
[Form] Deprecated usage of "choices" option in sub types
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | ~
Follows #21880 and the discussion in #20771.
Commits
-------
b5b56fcbac [Form] Deprecated usage of "choices" option in sub types
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Console] Add console.ERROR event and deprecate console.EXCEPTION
| Q | A |
| --- | --- |
| Branch | master |
| Bug fix? | yes |
| New feature? | yes |
| BC breaks? | no |
| Deprecations? | yes |
| Tests pass? | yes |
| Fixed tickets | - |
| License | MIT |
| Doc PR | todo |
## The Problem
The current `console.EXCEPTION` event is only dispatched for exceptions during the execution of `Command#execute()`. All other exceptions (e.g. the ones thrown by listeners to events) are catched by the `try ... catch` loop in `Application#doRunCommand()`. This means that there is _no way to override exception handling_.
## The Solution
This PR adds a `console.ERROR` event which has the same scope as the default `try ... catch` loop. This allows to customize all exception handling.
In order to keep BC, a new event was created and `console.EXCEPTION` was deprecated.
Commits
-------
c02a4c9857 Added a console.ERROR event
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security][SecurityBundle] Enhance automatic logout url generation
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
This should help whenever:
- [the token does not implement the `getProviderKey` method](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Http/Logout/LogoutUrlGenerator.php#L89-L99)
- you've got multiple firewalls sharing a same context but a logout listener only define on one of them.
##### Behavior:
> When not providing the firewall key:
>
>- Try to find the key from the token (unless it's an anonymous token)
>- If found, try to get the listener from the key. If the listener is found, stop there.
>- Try from the injected firewall key. If the listener is found, stop there.
>- Try from the injected firewall context. If the listener is found, stop there.
>
>The behavior remains unchanged when providing explicitly the firewall key. No fallback.
Commits
-------
5b7fe852aa [Security][SecurityBundle] Enhance automatic logout url generation
This PR was merged into the 3.3-dev branch.
Discussion
----------
301 status code must drop request method to GET.
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| BC breaks? | yes
| Tests pass? | yes
| Fixed tickets | #20924
| License | MIT
[RFC 7231 §6.4.2](https://tools.ietf.org/html/rfc7231#section-6.4.2) states that 301 HTTP Code should forward POST requests to the Location URI.
But, it also states that:
> For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.
This is the behavior implemented in almost all user agents.
However the `BrowserKit` did forward the method to the subsequent request.
This PR make the `BrowserKit` change the request method from POST to GET when the response status code is 301.
Commits
-------
abda966d75 301 status code must drop request method to GET.
[RFC 7231 §6.4.2](https://tools.ietf.org/html/rfc7231#section-6.4.2) states that 301 HTTP Code should forward POST requests to the Location URI.
But, it also states that:
> For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.
This is the behavior implemented in almost all user agents.
However the `BrowserKit` did forward the method to the subsequent request.
This PR was merged into the 3.3-dev branch.
Discussion
----------
[HttpKernel] Deprecate X-Status-Code for better alternative
| Q | A |
| --- | --- |
| Branch? | master |
| Bug fix? | no |
| New feature? | yes |
| BC breaks? | no |
| Deprecations? | yes |
| Tests pass? | yes |
| Fixed tickets | #12343 |
| License | MIT |
| Doc PR | https://github.com/symfony/symfony-docs/pull/6948 |
This marks the X-Status-Code header method of setting a custom response status
code in exception listeners for a better alternative. There is now a new method
on the `GetResponseForExceptionEvent` that allows successful status codes in
the response sent to the client.
The old method of setting the X-Status-Code header will now throw a deprecation warning.
Instead, in your exception listener you simply call `GetResponseForExceptionEvent::allowCustomResponseCode()` which will tell the Kernel not to override the status code of the event's response object.
Currenty the `X-Status-Code` header will still be removed, so as not to change the existing behaviour, but this is something we can remove in 4.0.
TODO:
- [x] Replace usage of X-Status-Code in `FormAuthenticationEntryPoint`
- [x] Open Silex issue
- [x] Rename method on the response
- [x] Ensure correct response code is set in `AuthenticationEntryPointInterface` implementations
- [x] Ensure the exception listeners are marking `GetResponseForExceptionEvent` as allowing a custom response code
- [x] In the Security component we should only use the new method of setting a custom response code if it is available, and fall back to the `X-Status-Code` method
Commits
-------
cc0ef282cd [HttpKernel] Deprecate X-Status-Code for better alternative
This PR was merged into the 3.3-dev branch.
Discussion
----------
[FrameworkBundle][Config] Move ConfigCachePass from FrameworkBundle to Config
| Q | A
| ------------- | ---
| Branch? | master<!--see comment below-->
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes/no
| Fixed tickets | - <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | <!--highly recommended for new features-->
This MR is part of the #21284 todo list
<!--
- Bug fixes must be submitted against the lowest 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 the master branch.
- Please fill in this template according to the PR you're about to submit.
- Replace this comment by a description of what your PR is solving.
-->
Commits
-------
bce445f452 Move ConfigCachePass from FrameworkBundle to Config
This PR was squashed before being merged into the 3.3-dev branch (closes#21792).
Discussion
----------
[Security] deprecate multiple providers in context listener
Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
Passing multiple user providers to the context listener does not make
much sense. The listener is only responsible to refresh users for a
particular firewall. Thus, it must only be aware of the user provider
for this particular firewall.
Commits
-------
53df0de7fc [Security] deprecate multiple providers in context listener
fbd9f88e31 [SecurityBundle] only pass relevant user provider
Passing multiple user providers to the context listener does not make
much sense. The listener is only responsible to refresh users for a
particular firewall. Thus, it must only be aware of the user provider
for this particular firewall.
This marks the X-Status-Code header method of setting a custom response
status code in exception listeners as deprecated. Instead there is now
a new method on the GetResponseForExceptionEvent that allows successful
status codes in the response sent to the client.
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Form][FrameworkBundle] Move FormPass to the Form component
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
So that anyone using only Form and DI can use it for registering form types/type guessers.
Follows #19443, related to #21284
Commits
-------
e68a6d963c [FrameworkBundle][Form] Move FormPass to the Form component
This PR was merged into the 3.3-dev branch.
Discussion
----------
[FrameworkBundle][Serializer] Move SerializerPass to the Serializer
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Part of #21284
Commits
-------
95cf5084c0 [FrameworkBundle][Serializer] Move SerializerPass to the Serializer
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Process] Deprecate not inheriting env vars + compat related settings
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | no
| Fixed tickets | -
| License | MIT
| Doc PR | -
Turning compat on/off is not a feature in itself.
About env vars: if one has unwanted env vars, one will still be able to remove them explicitly for the command. From my experience, not having eg PATH or HTTP_PROXY, etc. is more problematic. I'd prefer people to care about setting/unsetting the environment vars **they know about**, rather than allowing them to start with no ENV and discover later that they missed setting some var.
Commits
-------
df14451a73 [Process] Deprecate not inheriting env vars + compat related settings
Nicolas Grekas
Fabien Potencier
Jérôme Vasseur
HeahDude
Robin Chalas
Javier Eguiluz
Christian Flothmann
Jules Lamur
Thierry Thuon
Maxime STEINHAUSSER
Guilhem Niot
Deamon
James Halsall
David Buchmann
Guilhem N
Maxime Steinhausser
WouterJ