This PR was merged into the 3.4 branch.
Discussion
----------
[VarDumper] deal with errors being thrown on PHP 8
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Commits
-------
6175d528e8 deal with errors being thrown on PHP 8
This PR was merged into the 5.2-dev branch.
Discussion
----------
WebProfiler 5.2 is incompatible with HttpKernel 5.1
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
I have upgraded WebProfilerBundle to master in my project. Afterwards, the profiler crashes with the following error.
<img width="1049" alt="Bildschirmfoto 2020-09-17 um 21 45 23" src="https://user-images.githubusercontent.com/1506493/93520652-1a67a280-f92f-11ea-8f05-c72cbd996f19.png">
Looks like the changes of #36364 require HttpKernel to be bumped to 5.2 as well, so this PR suggests to do just that.
Commits
-------
115d6859d9 WebProfiler 5.2 is incompatible with HttpKernel 5.1
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[Cache] Allow cache tags to be objects implementing __toString()
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | maybe
| New feature? | maybe
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
`\Symfony\Contracts\Cache\CacheInterface::get(string $key, …)` implicitly converts objects with `__toString` while `CacheItem::tag()` will throw an exception. That’s a bit of a sharp edge.
Commits
-------
c2c03e050f [Cache] Allow cache tags to be objects implementing __toString()
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[HttpKernel] Do not override max_redirects option in HttpClientKernel
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#38207
| License | MIT
| Doc PR | -
As [proposed](https://github.com/symfony/symfony/issues/38207#issuecomment-693382336) by @nicolas-grekas this pull request removes the `max_redirects` setting in the `\Symfony\Component\HttpKernel\HttpClientKernel::handle` method.
It solves the issue that requests made by the `\Symfony\Component\HttpClient\CachingHttpClient` wouldn't follow redirects as described in the linked issue.
Commits
-------
981a11beed [HttpKernel] Do not override max_redirects option in HttpClientKernel
This PR was merged into the 5.1 branch.
Discussion
----------
[Security] Log notice when no entry point is configured
| Q | A
| ------------- | ---
| Branch? | 5.1
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | Fix#37068
| License | MIT
| Doc PR | -
In the new security system, authenticators are not necessarily authentication entry points. This can cause unexpected behavior if no entry point is configured. It's not really an error, that's why I choose the "notice" level: "Normal but significant events".
Commits
-------
68f891ff65 Log notice when no entry point is configured
This PR was squashed before being merged into the 5.2-dev branch.
Discussion
----------
[HttpClient] Added RetryHttpClient
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | /
| License | MIT
| Doc PR | TODO
This PR adds a new HttpClient decorator to automatically retry failed requests.
When calling API, A very small % of requests are expected to timeout due to transient network issues. Some providers like AWS recommends retrying these requests and use a lower connection timeout so that the clients can fail fast and retry.
I used the almost the same configuration as Messenger
```yaml
framework:
http_client:
default_options:
retry_failed:
enabled: true // default false
decider_service: null
backoff_service: null
http_codes: [423, 425, 429, 500, 502, 503, 504, 507, 510]
max_retries: 3
delay: 1000
multiplier: 2
max_delay: 0
response_header: true
scoped_clients:
github:
scope: 'https://api\.github\.com'
retry_failed:
max_delay: 2000
```
Commits
-------
712ac5999d [HttpClient] Added RetryHttpClient
This PR was squashed before being merged into the 5.2-dev branch.
Discussion
----------
[Security] Added login throttling feature
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix#37266
| License | MIT
| Doc PR | tbd
This "recreates" #37444 based on the RateLimiter component from #37546 <s>(commits are included in this branch atm)</s>.
Login throttling can be enabled on any user-based authenticator (thanks to the `UserBadge`) with this configuration:
```yaml
security:
firewalls:
default:
# default limits to 5 login attempts per minute, the number can be configured via "max_attempts"
login_throttling: ~
# or you can define your own RateLimiter on framework.rate_limiter and configure it instead:
login_throttling:
limiter: login
```
Commits
-------
afdd805b1c [Security] Added login throttling feature
This PR was merged into the 4.4 branch.
Discussion
----------
[HttpClient] Support for CURLOPT_LOCALPORT
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | https://github.com/symfony/symfony/issues/38081#issuecomment-688166943
| License | MIT
| Doc PR | N/A
Commits
-------
45fa6b8f24 [HttpClient] Support for CURLOPT_LOCALPORT.
This PR was merged into the 4.4 branch.
Discussion
----------
Upgrade PHPUnit to 8.5 (php 7.2) and 9.3 (php >= 7.3)
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | #37564
| License | MIT
| Doc PR | N/A
This is #38103 on the 4.4 branch.
Commits
-------
73647e5ffe Upgrade PHPUnit to 8.5 (php 7.2) and 9.3 (php >= 7.3).
This PR was merged into the 3.4 branch.
Discussion
----------
Patch YAML superfluous cast
| Q | A
| ------------- | ---
| Branch? | master for features / 3.4, 4.4 or 5.1 for bug fixes <!-- see below --> - 3.4 as branch to patch against as documented
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | -/- <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
Commits
-------
05a9660a1e remove superfluous cast
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Amqp] Add amqps support
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | Fix#37002
| License | MIT
| Doc PR | symfony/symfony-docs#... TODO <!-- required for new features -->
### Cases
_Case 1 (simple):_
I want to set up my app with a locally installed amqp broker supporting SSL. No auth is needed, no vhost, only SSL certificate file located at /etc/ssl/cafile.
'amqps://'
_Case 2 (complex):_
I use a special port, special file locations for SSL. I pass it through php.ini or configuration.
### Questions
1) Actually AmqpTransportFactory use `supports` function to see if 'amqp://' is contained in dsn string and accept cacert argument to use SSL
How are we supposed to cover AMQPS's case in your opinion?
cacert argument is settable through php.ini and code.
### Observations
I think this PR should aim at:
- Having correct defaults ssl values in case of 'amqps://' eg : case 1
- Being able to pass cacert file path and verify argument. eg : case 2
- Test: but test what?
#### EDIT
As discuted with @nicolas-grekas, we should check that cacert is existing in php.ini or is passed in configuration and throw an exception to give a nice feedback about what's wrong. Php amqp lib isn't actually precise about why it fails when you forget it.
### Steps
- [x] Ensure AMQPS can be used out of the box without DSN.
- [x] If not, try to modify vendor directly to fix it.
- [x] Modify vendor to make AMQPS works with DSN.
- [x] Check cacert to throw a better exception.
- [x] Add test related to last point.
- [ ] Pass CI
Commits
-------
99fc3f3b89 [Amqp] Add amqps support
This PR was squashed before being merged into the 5.2-dev branch.
Discussion
----------
[RFC] Introduce a RateLimiter component
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Refs #37444
| License | MIT
| Doc PR | tbd
Based on the discussions in #37444, I decided to write a general purpose RateLimiter component. This implementation uses the token bucket algorithm, inspired by the [Go's time/rate](3af7569d3a/rate/rate.go) library and the [PHP `bandwidth-throttle/token-bucket` package](https://github.com/bandwidth-throttle/token-bucket) (which is [unmaintained for years](https://github.com/bandwidth-throttle/token-bucket/issues/19)).
### Usage
The component has two main methods:
* `Limiter::reserve(int $tokens, int $maxTime)`, allocates `$tokens` and returns a `Reservation` containing the wait time. Use this method if your process wants to wait before consuming the token.
* `Limiter::consume(int $tokens)`, checks if `$tokens` are available now and discards the reservation if that's not the case. Use this method if you want to skip when there are not enough tokens at this moment.
The component uses the Lock component to make sure it can be used in parallel processes.
Example:
```php
<?php
namespace App\EventListener;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Event\RequestEvent;
use Symfony\Component\RateLimiter\LimiterFactory;
class LimitListener
{
private $limiterFactory;
public function __construct(LimiterFactory $apiLimiterFactory)
{
$this->limiterFactory = $apiLimiterFactory;
}
public function __invoke(RequestEvent $event)
{
$ip = $event->getRequest()->getClientIp();
$limiter = $this->limiterFactory->createLimiter(preg_replace('/[^a-zA-Z0-9]/', '-', $ip));
if (!$limiter->consume()) {
$event->setResponse(new Response('Too many requests', 429));
}
}
}
```
### Usefullness of the component
I think a generic rate limiter is usefull in quite some places:
* Add a login throttling feature in Symfony
* <s>Rate limiting outgoing API calls (e.g. HttpClient), to prevent hitting upstream API limits.</s> See #37471 (and https://blog.heroku.com/rate-throttle-api-client )
* Allowing users to easily implement API rate limits in their own Symfony-based APIs.
### State of the art
There are some rate limiting packages in PHP, but I think there is no precendent for this component:
* [`graham-campbell/throttle`](https://github.com/GrahamCampbell/Laravel-Throttle) is heavily relying on Laravel. It is however very popular, proofing there is a need for such feature
* [`nikolaposa/rate-limit`](https://github.com/nikolaposa/rate-limit) does not implement reservation of tokens and as such less feature complete. Also its architecture combines the rate limiter and storage, making it harder to implement different storages.
### Todo
If it is agreed that this component can bring something to Symfony, it needs some more love:
* [x] Add more tests
* [x] Integrate with the FrameworkBundle
* [x] Add sliding window implementation
* [x] Add integration with the Security component
* <s>Maybe add more storage implementations? I didn't want to duplicate storage functionalities already existing in the Lock and Cache component, thus I for now focused mostly on integrating the Cache adapters. But maybe a special Doctrine adapter makes sense?</s>
Commits
-------
67417a693e [RFC] Introduce a RateLimiter component
This PR was merged into the 5.2-dev branch.
Discussion
----------
Make RetryTillSaveStore implements the SharedLockStoreInterface
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | /
| License | MIT
| Doc PR | /
The `RetryTillSaveStore` decorates a non blocking store (ie. `RedisStore`) to make it blockable.
The issue is: if the decorate store manage SharedLock, the Decorator does not implements this interface. It's currently not possible to get both `blocking` and `sharable` store.
Commits
-------
a0321e66c9 Make RetryTillSaveStore implements the SharedLockStoreInterface
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Form] Add new way of mapping data using callback functions
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | yes
| Tickets | Fix#37597 (partially)
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/14241
Replaces https://github.com/symfony/symfony/pull/37614
## What this solves
Objects and Forms have different mechanisms for structuring data. When you build an object model with a lot of business logic it's valuable to use these mechanisms to better collect the data and the behavior that goes with it. Doing so leads to variant schemas; that is, the object model schema and the form schema don't match up.
You still need to transfer data between the two schemas, and this data transfer becomes a complexity in its own right. If the objects know about the form structure, changes in one tend to ripple to the other.
Currently, the Data Mapper layer separates the objects from the form, transfering data between the two and also isolating them from each other. That's fine, but at present the default data mapper has a limitation: _it's very tied to one property path_ (see [`PropertyPathMapper`](https://github.com/symfony/symfony/blob/5.1/src/Symfony/Component/Form/Extension/Core/DataMapper/PropertyPathMapper.php)).
That said, you'll have to write your own data mapper in the following situations:
* When the property path differs for reading and writing
* When several form fields are mapped to a single method
* When you need to read data based on the model's state
* When the mapping of the model depends on the submitted form data
* ...
Also, when we create a new data mapper, we usually forget about checking the status of the given data and forms. Whether the data is empty or not; throw an exception if the given data is not an object/array and whether the form field is submitted/synchronized/disabled or not. Not doing that could lead to unwanted behavior.
## What this proposes
Create a new way to write and read values to/from an object/array using callback functions. This feature would be tied to each form field and would also mean a new way of mapping data, but a very convenient one, in which it won't be necessary to define a new data mapper and take into account all what it would imply when you only need to map one field in a different manner or perhaps in only one direction (writing or reading the value).
This PR adds two new options for each form type: `getter` and `setter`, allowed to be `null` or `callable`:
```php
$builder->add('name', TextType::class, [
'getter' => function (Person $person, FormInterface $form): string {
return $person->firstName().' '.$person->lastName();
},
'setter' => function (Person &$person, ?string $name, FormInterface $form): void {
$person->rename($name);
},
]);
```
This would give us the same possibilities as data mappers, but within the form field scope, where:
* `$person` is the view data, basically the underlying data to the form.
* `$form` is the current child form that is being mapped.
* `$name` is the submitted data that belongs to that field.
These two callbacks will be executed following the same rules as for property paths before read and write any value (e.i. early return if empty data, skip mapping if the form field is not mapped or it's disabled, etc).
## What this also proposes
I based the implementation on solving this problem first:
> https://github.com/symfony/symfony/pull/37614#issuecomment-662957865
> [...] the property_path option defines the rules on how it's accessed. From there, the actual way it is accessed (direct property access, accessors, reflection, whatever) are hidden from view. All that matters is the property path (which is deduced from the name if not explicitly set). [...]
So splitting the default data mapper `PropertyPathMapper` into two artifacts: "[DataMapper](https://github.com/yceruto/symfony/blob/data_accessor/src/Symfony/Component/Form/Extension/Core/DataMapper/DataMapper.php)" and "[DataAccessor](https://github.com/yceruto/symfony/blob/data_accessor/src/Symfony/Component/Form/DataAccessorInterface.php)" would allow us adding multiple data accessors along the way (the code that varies in this case) without having to reinvent the wheel over and over again (the data mapper code).
You can also think about a new `ReflectionAccessor` for instance? or use this `CallbackAccessor` to map your form partially from an external API? yes, you could do it :)
Here is a view of the proposed changes:
Where "DataMapper" will take care of common checks, iterates the given child forms, manages the form data and all what is needed for mapping a standard form, whereas "DataAccessor" will take care of how to read and write values to/from the underlying object or array.
## BC
The `PropertyPathMapper` is being deprecated in favor of `DataMapper` class, which uses the `PropertyPathAccessor` by default.
Although `DataMapper` is now the default for each compound form, the behavior must remains the same (tests prove it). So that if `getter` or `setter` option is null (they're by default) the `CallbackAccessor` will falls back to `PropertyPathAccessor` either for reading or writing values.
---
Sorry for the long description, but I think that sometimes it is necessary for too complex issues and big changes. Besides, now you know a little more about what these changes is about.
/cc @xabbuh as creator of [rich-model-forms-bundle](https://github.com/sensiolabs-de/rich-model-forms-bundle) and @alcaeus as you had worked on this issue.
WDYT?
Commits
-------
878effaf47 add new way of mapping data using callback functions
This PR was merged into the 4.4 branch.
Discussion
----------
[Messenger] Minor fix of exception message formatting
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
See e.g. 2f27613557
Commits
-------
69187ac9ce Fixed exception message formatting
This PR was merged into the 5.2-dev branch.
Discussion
----------
[String] allow translit rules to be given as closure
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix#35061
| License | MIT
| Doc PR | -
Instead of trying to fix#35061 at our level, I propose to add a hook so that ppl can use a transliterator that fits their need (eg voku/portable-ascii or behat/transliterator) while still relying on the `SluggerInterface`.
Commits
-------
0bb48df2b0 [String] allow translit rules to be given as closure
This PR was merged into the 4.4 branch.
Discussion
----------
[FrameworkBundle] Fix xsd definition which prevent to add more than one workflow metadata
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Fix xsd definition which prevent to add more than one workflow metadata (only in xml configuration format)
Commits
-------
94e390b96a [FrameworkBundle] Fix error in xsd which prevent to register more than one metadata
This PR was merged into the 4.4 branch.
Discussion
----------
[Console] work around disabled putenv()
If this is set to true, then putenv functions simply won't be run in this script, making this function usable on servers, where putenv is disabled
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
Commits
-------
d3f909bff3 [Console] work around disabled putenv()
This PR was merged into the 3.4 branch.
Discussion
----------
[Form] Change 'cache_key' to AbstractRendererEngine::CACHE_KEY_VAR in BaseType
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| License | MIT
The purpose of this change is to find all usages of AbstractRendererEngine::CACHE_KEY_VAR. Currently, if you search for AbstractRendererEngine::CACHE_KEY_VAR you will see only access to it, i.e. (`$view->vars[AbstractRendererEngine::CACHE_KEY_VAR]`), but you can't find it in write level. With this pull request you can see where is was used for write.
Commits
-------
4fcb41c3ba Change 'cache_key' to AbstractRendererEngine::CACHE_KEY_VAR
This PR was merged into the 4.4 branch.
Discussion
----------
[PhpUnitBridge] Fix error with ReflectionClass
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| License | MIT
Introduced in #38094. Wish I know how I missed that.
Commits
-------
ed1bffeed7 [PhpUnitBridge] Fix error with ReflectionClass
This PR was merged into the 5.1 branch.
Discussion
----------
[Notifier] Fix errors parsing in FirebaseTransport
| Q | A
| ------------- | ---
| Branch? | 5.1
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | /
| License | MIT
| Doc PR | /
I noticed that, when parsing the response, this transport use `getHeader()` like a `string[]` instead of `string[][]`.
I did not test it and I'm not sure about this fix: could you have a look @Jeroeny ?
Commits
-------
2818e2cd43 Fix errors parsing in FirebaseTransport
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[HttpClient][HttpClientTrait] don't calculate alternatives if option is auth_ntlm
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | no
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
If option is `auth_ntlm` an exception is thrown, `$alternatives` then is not used.
Commits
-------
ab1a96c999 [HttpClient][HttpClientTrait] don't calculate alternatives if option is auth_ntlm
