* 3.2:
fixed tests
fixed merge
Fix minor phpdoc mismatches with the code(detected by phan)
[Asset] Starting slash should indicate no basePath wanted
[Security] Fix phpdoc logout listener
[EventDispatcher] fix getting priorities of listeners during dispatch
Add iconv extension to suggested dependencies
Fix minor typo in the main README.md
Allow Upper Case property names in ObjectNormalizer
[EventDispatcher] fix: unwrap listeners for correct info
* 2.8:
Fix minor phpdoc mismatches with the code(detected by phan)
[Asset] Starting slash should indicate no basePath wanted
[Security] Fix phpdoc logout listener
Add iconv extension to suggested dependencies
Fix minor typo in the main README.md
Allow Upper Case property names in ObjectNormalizer
[EventDispatcher] fix: unwrap listeners for correct info
* 2.7:
Fix minor phpdoc mismatches with the code(detected by phan)
[Asset] Starting slash should indicate no basePath wanted
[Security] Fix phpdoc logout listener
Fix minor typo in the main README.md
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Profiler] DataCollector: Remove unused static property
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
Unless I missed something, any usage of this property were removed in https://github.com/symfony/symfony/pull/21638.
Commits
-------
96743e69ad [Profiler] DataCollector: Remove unused static property
This PR was merged into the 3.3-dev branch.
Discussion
----------
Making tags under _defaults always apply
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22497
| License | MIT
| Doc PR | n/a
Obviously, things under `_defaults` are applied to all services in that file. However, tags was an exception: it was *not* applied unless you have `inherit_tags`. The correct behavior is subjective, but after talking about it today, we (mostly) decided that tags *should* always apply. This does exactly that.
One side-effect (explained in the commit message) is that if you have a parent and child service both in the same file, the tag from `_defaults` is applied twice. I think that makes sense, and at some point, we can't protect the users from their own configuration :). This kind of "weird" behavior is likely not a problem, as compiler passes now handle multiple tags well AND it only affects a case where the user has added tags to `_defaults` *and* is using parent-child definitions. That's quite a strange mixture of conditions :).
Cheers!
Commits
-------
037a782b91 Making tags under _defaults always apply and removing inherit_tags entirely
Now that inherit_tags has been removed, 3.3 has the same functionality as 3.2: tags
are *never* cascaded from parent to child (but you tags do inherit from defaults
to a service and instanceof to a service).
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Lock] remove the component from 3.3
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22580
| License | MIT
| Doc PR | n/a
As decided in #22580, we will read the Lock component in 3.4.
Commits
-------
37ec869511 [Lock] remove the component from 3.3
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] json login listener: ensure a json response is sent on bad request
| Q | A
| ------------- | ---
| Branch? | master (3.3)
| Bug fix? | yesish
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
I would have simply recommended to set the proper format when declaring the route:
```yml
# routing.yml
api_login:
path: /login
defaults: { _format: json }
```
but, since https://github.com/symfony/symfony/pull/22477 has been merged, and considering https://github.com/symfony/symfony/pull/22477#issuecomment-295897629:
> my point above regarding checking the content type is so that one could use form_login and json_login in parallel on the same routes and within the same firewall
we may consider setting the request format to json when throwing the `BadRequestHttpException`, so used conjointly with the TwigBundle, the exception is rendered using the `exception.json.twig` template.
ping @lsmith77
(An alternative would be to check the Accept header to set the request format to json if it's the preferred one instead of doing it each time we throw the exception. But Symfony never used such content negotiation AFAIK, and I think it's safe enough to assume someone sending json is expecting json as ouput for exceptions.)
Commits
-------
4427cf9157 [Security] json login listener: ensure a json response is sent on bad request
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Fix invalid callables dumped for ArgumentInterface objects
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
Follow up of #22511, from @iltar:
> Currently, when having a service definition which has more than 1 usage of that service, it will put the argument in `$a` for example. By doing so, it will also use `$a` in the callable of the `ServiceLocator`, which result in an undefined variable `$a`.
> I managed to trigger this with the translator service, where I have my own loader, that I add for NL and EN, causing 2 method calls to turn the direct getter into a variable. I've added 2 test cases, 1 with only 1 method call and 1 with 2 method calls.
Commits
-------
f81c577 [DI] Test references inside ServiceLocator are not inlined
8783602 [DI] Fix invalid callables dumped for ArgumentInterface objects
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Throw useful exception on bad XML argument tags
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22525
| License | MIT
| Doc PR | -
I still think that the feature request in #22525 would make things better.
But at least, let's make thing fail loudly, instead of silently today, with the associated usual wtfs :)
Commits
-------
91828ecd17 [DI] Throw useful exception on bad XML argument tags
This PR was squashed before being merged into the 2.7 branch (closes#22453).
Discussion
----------
Fix minor phpdoc mismatches with the code(detected by phan)
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | no
Fix minor mismatches between phpdoc and the type of the code itself, detected by etsy/phan (Prevent confusion in the future)
The actual return types of a few functions have changed from int to bool where preg_match or `&` was used.
Fix optional param before required param in src/Symfony/Component/Serializer/Normalizer/AbstractObjectNormalizer.php
The config used and the rest of the output is at https://gist.github.com/TysonAndre/91bed0e16583301f1e6e5cc2a4807081 (Uses some patches to etsy/phan that weren't merged to master yet)
Commits
-------
12f1239565 Fix minor phpdoc mismatches with the code(detected by phan)
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] add Request type json check in json_login
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no, unreleased feature
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR | -
follow up to https://github.com/symfony/symfony/pull/22425 to limit the `UsernamePasswordJsonAuthenticationListener` to only requests with appropriate JSON content type.
I am not entirely happy with this implementation but mostly because Symfony out of the box only provides very limited content type negotiation. I guess anyone that wants to tweak the content negotiation will simply need to ensure the Request::$format is set accordingly before the code is triggered.
Commits
-------
045a36b303 add Request type json check in json_login
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Serializer] Add missing normalizer options constants
| Q | A
| ------------- | ---
| Branch? | master (3.3)
| Bug fix? | not really
| New feature? | yesish, but for 3.3 as those options were added on this branch and not released yet
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/22537#discussion_r113719848
| License | MIT
| Doc PR | N/A
As seen in https://github.com/symfony/symfony/pull/22537#discussion_r113719848.
@dunglas : I'm not sure about the exposing the `key_type` option as a constant in `ArrayDenormalizer`/`AbstractObjectNormalizer`, as it looks more or less like a detail of the AbstractObjectNormalizer implementation, but anyway it should be in 3.2 if we add it, so I haven't included it here.
However, I wonder if this option shouldn't directly accept a string too, rather than just a `Symfony\Component\PropertyInfo\Type` instance if we want to consider this option "public"?
Commits
-------
b0c414f2c8 [Serializer] Add missing normalizer options constants
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Serializer] Allow to pass csv encoder options in context
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
CSV contents typically are provided by one or many third-parties, not always allowing you to get control over the provided format. In case you need to import csv files with different formats, either you have to instantiate a decoder yourself/inject it instead of the main serializer instance, either you need another serializer instance with a differently configured csv encoder registered within.
This PR allows to configure any encoder option through the context, so you can keep injecting and using the same serializer instance.
Commits
-------
10a76aac15 [Serializer] Allow to pass csv encoder options in context
This PR was merged into the 2.8 branch.
Discussion
----------
Allow Upper Case property names in ObjectNormalizer
| Q | A
| ------------- | ---
| Branch? | 2.8
| Bug fix? | yes
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22547
| License | MIT
Same problem that has been fixed here https://github.com/symfony/symfony/pull/22265
and here https://github.com/api-platform/core/pull/1037
ObjectNormalizer returns $id instead of $Id. It is bad naming convention, but is possible
```php
class Entity {
protected $Id;
public function getId()
{
return $this->Id;
}
}
```
Commits
-------
b2b4faa3c0 Allow Upper Case property names in ObjectNormalizer
This PR was merged into the 2.8 branch.
Discussion
----------
[VarDumper] Add iconv dependency
| Q | A
| ------------- | ---
| Branch? | 2.8
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Alternative to #20927.
I still think adding `@requires extension iconv` to the related tests would be nice though: on some PHP setups the iconv extension is not available by default, those tests will fail and result in red errors when running the test suite, even when working on something unrelated. The test would still run on CI so it's fine IMO.
Should I add `ext-iconv` and/or `symfony/polyfill` to `require-dev`?
/cc @nicolas-grekas
Commits
-------
13f17079ef Add iconv extension to suggested dependencies
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] Handle bad request format in json auth listener
| Q | A
| ------------- | ---
| Branch? | master (3.3)
| Bug fix? | yesish
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
In https://github.com/symfony/symfony/pull/22034, I wondered myself if we shouldn't throw a dedicated exception to handle bad formatted requests and give more inputs to the client by returning a 400 response with an explicit message.
~~Here is a suggestion, introducing a new `BadRequestFormatException` and using it in `UsernamePasswordJsonAuthenticationListener` whenever there is no custom failure handler set (but someone using its own handler should be able to treat the failure properly too).~~
As discussed with @chalasr , it seems better to directly throw a `BadRequestHttpException` as it's actually out of the whole security process. PR updated.
Commits
-------
93a8cb9cd4 [Security] Handle bad request format in json auth listener
This PR was squashed before being merged into the 3.3-dev branch (closes#22551).
Discussion
----------
[Process] Ecaping of CLI arguments containing slashes on Windows
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22549
| License | MIT
Actually only the first argument - the command needs to be escaped but that would need another condition. I think it should be OK.
Commits
-------
0d073128de [Process] Ecaping of CLI arguments containing slashes on Windows