This PR was squashed before being merged into the 4.4 branch (closes#33584).
Discussion
----------
[Security] Deprecate isGranted()/decide() on more than one attribute
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | yes
| Tickets | -
| License | MIT
| Doc PR | tbd
While I expect it not be used much, it is currently possible to call `isGranted()` on more than one attribute:
```php
if ($this->authorizationChecker->isGranted(['ROLE_USER', 'ROLE_ADMIN'])) {
// ...
}
```
Supporting this includes a couple of problems/questions:
- It is not clear whether this is `OR` or `AND`;
- In fact, this is left over to the voter to decide upon. So it can vary for each voter and writers of new voters need to consider this (otherwise, you get issues like https://github.com/LeaseWeb/LswSecureControllerBundle/issues/4 );
- It promotes to vote over roles instead of actions.
I think we can do better. In the past, we've created all tooling for this to be self-explaining and easier:
```php
// ExpressionLanguage component (also includes other functions, like `is_granted('EDIT')`)
if ($this->authorizationChecker->isGranted("has_role('ROLE_USER') or has_role('ROLE_ADMIN')")) {
// ...
}
// calling it multiple times in PHP (may reduce performance)
if ($this->authorizationChecker->isGranted('ROLE_USER')
|| $this->authorizationChecker->isGranted('ROLE_ADMIN')
) {
// ...
}
// or by using Role Hierarchy, if a user really wants to vote on roles
```
This PR deprecates passing more than one attribute to `isGranted()` and `decide()` to remove this confusing bit in Security usage.
Backwards compatiblity help
---
I need some help in how to approach changing the `VoterInterface::vote(TokenInterface $token, $subject, array $attributes)` method in a backwards compatible way. Removing `array` breaks all Voters, so does changing it to `string` and removed the parameter all together.
Commits
-------
c64b0beffb [Security] Deprecate isGranted()/decide() on more than one attribute
This PR was merged into the 4.4 branch.
Discussion
----------
Allow configuring class names through methods instead of class parameters in Doctrine extensions
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
While removing class parameters for DoctrineBundle 2.0 (see https://github.com/doctrine/DoctrineBundle/issues/630), I noticed that the DoctrineExtension still requires them. This PR adds a new method that keeps legacy behaviour, but will dropped in Symfony 5. Extending classes (mainly DoctrineBundle and DoctrineMongoDBBundle) must implement this method themselves to return the appropriate class names instead of declaring them as class parameters in their service configuration. I'll create a separate for the master branch to make this method abstract in 5.0.
The cache driver class names are not being replaced in this PR, as we're dropping support for `doctrine/cache` in DoctrineBundle 2.0. A separate PR will be created to handle those deprecations and to clean up the code.
Commits
-------
b53d8ccfc1 [DoctrineBridge] Allow configuring class names through methods instead of class parameters
This PR was merged into the 4.4 branch.
Discussion
----------
[HttpKernel] deprecate global dir to load resources from
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #31915 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR |
Replaces #31958
Here two example deprecations by adding files in the deprecated locations:
```
Overwriting the resource "@AcmeBundle/Resources/config/routing.yaml" with "/vagrant/src/Resources/AcmeBundle/config/routing.yaml" is deprecated since Symfony 4.4 and will be removed in 5.0.
Loading the file "foobar.yaml" from the global resource directory "/vagrant/src" is deprecated since Symfony 4.4 and will be removed in 5.0.
```
Commits
-------
aa82566f76 [HttpKernel] deprecate global dir to load resources from
This PR was merged into the 4.4 branch.
Discussion
----------
[Translation] deprecate support for null locales
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
Commits
-------
e6b6a9d33a deprecate support for null locales
This PR was squashed before being merged into the 4.4 branch (closes#32845).
Discussion
----------
[HttpKernel][FrameworkBundle] Add alternative convention for bundle directories
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/32453
| License | MIT
| Doc PR | TODO
We already know that bundles must be compatible with many Symfony's versions, so it is very likely that current bundles won't be able to use this feature soon, unless they create symbolic links to support both structures.
The point is that this is already happening, so in the future when our bundles stop to support <=4.3 then you'll be sure to change the current directory structure.
We have recently added the `getPublicDir()` method in https://github.com/symfony/symfony/pull/31975, here I'm removing it in favor of hardcoding a new convention.
I've added some functional tests in which I've changed everything to this structure:
```
-- ModernBundle
|-- config/
|-- public/
|-- src/
|-- ModernBundle.php
|-- templates/
|-- translations/
```
WDYT?
Commits
-------
6996e1cbe2 [HttpKernel][FrameworkBundle] Add alternative convention for bundle directories
This PR was merged into the 4.4 branch.
Discussion
----------
[HttpFoundation] deprecate HeaderBag::get() returning an array and add all($key) instead
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | maybe <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #31317 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | todo <!-- 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.
-->
the $first param has been deprecated in the get methid
and we are adding a $key parameter to all to get all values from a key as arrays
Do we deprecated the get method ? if so this will be a little bigger in terms of changes.
Commits
-------
2c5a8f1bdf [HttpFoundation] deprecate using $first in get and added key in all
This PR was merged into the 4.4 branch.
Discussion
----------
[Ldap] Add security LdapUser and provider
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Moves `LdapUserProvider` from `Security\Core` to the Ldap component, the provider now deals with a new `LdapUser` aware of its ldap `Entry` (should help in #31843).
Commits
-------
6736cdfec3 [Ldap] Add security LdapUser and provider
This PR was merged into the 4.4 branch.
Discussion
----------
[WebProfilerBundle] Decoupling TwigBundle and using the new ErrorRenderer mechanism
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/31398#discussion_r303213713
| License | MIT
| Doc PR | -
Commits
-------
846d3e0e58 Decoupling TwigBundle and using the new ErrorRenderer mechanism
This PR was merged into the 4.4 branch.
Discussion
----------
[Process] Deprecate Process::inheritEnvironmentVariables()
| Q | A
| ------------- | ---
| Branch? | 4.4 <!-- see below -->
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
IIUC, this method was kept as a BC layer from 3.4 to 4.0 to switch to the "inherit env vars" behavior, inciting developers to opt-in in 3.4. Since 4.0, env vars are always inherited, and this method doesn't allow to opt-out. So, time to remove it?
---
refs:
- https://github.com/symfony/symfony/pull/21470
- https://github.com/symfony/symfony/pull/22836
Commits
-------
af9bad31c6 [Process] Deprecate Process::inheritEnvironmentVariables()
This PR was squashed before being merged into the 4.4 branch (closes#32492).
Discussion
----------
[Lock] feature: lock split interface fix post-merge review
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yesish <!-- 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 | none <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | none <!-- 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.
-->
see https://github.com/symfony/symfony/pull/32198#pullrequestreview-259854210
Commits
-------
8173c475f3 [Lock] feature: lock split interface fix post-merge review
This PR was squashed before being merged into the 4.4 branch (closes#32471).
Discussion
----------
Add a new ErrorHandler component (mirror of the Debug component)
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
On top of https://github.com/symfony/symfony/pull/32470
Commits
-------
b1b6e80a3d Add a new ErrorHandler component (mirror of the Debug component)
This PR was merged into the 4.4 branch.
Discussion
----------
[Cache] Add argument $prefix to AdapterInterface::clear()
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This PR allows clearing `AdapterInterface` implementations by prefix of keys. The goal is to fix an edge case situation in `ProxyAdapter`: right now, when one calls `->clear()` on a proxy adapter that is configured to add a prefix to all the keys passed to the decorated pool, we clear it all; while only the subset that starts with the prefix should be.
Since `AdapterInterface` is an "internal" interface (ie its purpose is to create compatible implementations - *NOT* to be type-hinted for), this is not really a user-facing change.
/cc @Nyholm, this came out after we talked about proxified chain pools
Commits
-------
ad6f6cf900 [Cache] Add argument $prefix to AdapterInterface::clear()
This PR was merged into the 4.4 branch.
Discussion
----------
[Validator] Add a Length::$allowEmptyString option to reject empty strings
| Q | A
| ------------- | ---
| Branch? | 4.4 <!-- see below -->
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | Todo (change the warning on top of https://symfony.com/doc/current/reference/constraints/Length.html)
which defaults to `true` in 4.4 but will trigger a deprecation if not set explicitly
in order to make the default `false` in 5.0.
While it could be solved now thanks to #29641 by using both `@Length(min=1)` & `@NotBlank(allowNull=true)` constraints,
as expressed in https://github.com/symfony/symfony/issues/27876#issuecomment-403307783 and following comments, the `@Length(min=1)` behavior doesn't match our expectations when reading it: it feels logical to invalidate empty strings, but it actually doesn't.
Hence the proposal of making the behavior of rejecting empty strings the default in 5.0.
In my opinion, the flag could even be removed later.
Commits
-------
e113e7f812 [Validator] Add a Length::$allowEmptyString option to reject empty strings
This PR was merged into the 4.4 branch.
Discussion
----------
[Filesystem] deprecate calling isAbsolutePath with a null
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
This PR is a result of #32247 and deprecates calling `Filesystem::isAbsolutePath()` with a `null` value.
Commits
-------
93190182f6 [Filesystem] depreacte calling isAbsolutePath with a null
This PR was squashed before being merged into the 4.4 branch (closes#32269).
Discussion
----------
[PropertyAccess] Adds entries to CHANGELOG and UPGRADE
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #32179 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
In PR #32241 I missed to add entries to the CHANGELOG and UPGRADE file.
Commits
-------
c4afbf376f [PropertyAccess] Adds entries to CHANGELOG and UPGRADE
