This PR was merged into the 3.4 branch.
Discussion
----------
[Security] don't do nested calls to serialize()
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #29951
| License | MIT
| Doc PR | n/a
The problem (originally reported as `Symfony\Component\Security\Core\Authentication\Token\AbstractToken` issue), may occur also in classes extending `Symfony\Component\Security\Core\Exception\AuthenticationException`
Tasks:
- [x] Skip native serializer (workaround itself)
- [x] Token test
- [x] Exception test
Commits
-------
10256fc4fd skip native serialize among child and parent serializable objects
41000f1de0 [Security] dont do nested calls to serialize()
This PR was merged into the 3.4 branch.
Discussion
----------
[FrameworkBundle] Support use of hyphen in asset package name
This PR is a continuity of #28128
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #29122
| License | MIT
| Doc PR | n/a
According to issue https://github.com/symfony/symfony-docs/pull/10442, we tested in a demo bundle, for example in src/AppBundle/Resources/config/config.yml a package using hyphens: app-client-frontend, and withouth the patch it fails because the package is not recognized. With the patch, it works as expected.
```yaml
framework:
assets:
packages:
app-client-frontend:
version: "%env(FRONTEND_VERSION)%"
version_format: '%%2$s/dist/%%1$s'
base_urls:
- "%env(FRONTEND_URL)%"
```
Commits
-------
5c58b6e875 Add PackageNameTest to ConfigurationTest also add in the changelog the corresponding entry to this PR
30b6a4f7bf Support use of hyphen in asset package name
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no
| Tests pass? | yes (Manual tests only)
| Fixed tickets | #28122
| License | MIT
| Doc PR | n/a
According to issue https://github.com/symfony/symfony-docs/pull/10442, we tested in a demo bundle, for example in src/AppBundle/Resources/config/config.yml a package using hyphens: app-client-frontend, and withouth the patch it fails because the package is not recognized. With the patch, it works as expected.
```
framework:
assets:
packages:
app-client-frontend:
version: "%env(FRONTEND_VERSION)%"
version_format: '%%2$s/dist/%%1$s'
base_urls:
- "%env(FRONTEND_URL)%"
```
This PR was merged into the 3.4 branch.
Discussion
----------
Replace gender by eye color in tests
| Q | A
| ------------- | ---
| Branch? | 3.4 <!-- see below -->
| Bug fix? | yes
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #29737 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | <!-- required for new features -->
<!--
Write a short README entry for your feature/bugfix here (replace this comment block.)
This will help people understand your PR and can be used as a start of the Doc PR.
Additionally:
- 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.
-->
I've slightly changed @derrabus proposition to use color only because of the potentially racist interpretation when used for a person, open for discussion though.
Commits
-------
72180342b7 Replace gender by eye color in tests
This PR was submitted for the master branch but it was squashed and merged into the 3.4 branch instead (closes#29764).
Discussion
----------
[HttpFoundation] Check file exists before unlink
Check file exists to prevent ErrorException
| Q | A
| ------------- | ---
| Branch? | 2.6 <!-- see below -->
| Bug fix? | yes
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
<!--
Write a short README entry for your feature/bugfix here (replace this comment block.)
This will help people understand your PR and can be used as a start of the Doc PR.
Additionally:
- 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.
-->
Commits
-------
1954187fac [HttpFoundation] Check file exists before unlink
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpFoundation] MemcachedSessionHandler::close() must close connection
| Q | A
| ------------- | ---
| Branch? | 3.4 <!-- see below -->
| Bug fix? | yes
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| License | MIT
Intoduced here https://github.com/symfony/symfony/pull/3333
Commits
-------
38a9d8b6a3 [Bugfix] MemcachedSessionHandler::close() must close connection
This PR was squashed before being merged into the 3.4 branch (closes#29844).
Discussion
----------
[Console] Fixed#29835: ConfirmationQuestion with default true for answer '0'
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | Almost all, one failure on appveyor?
| Fixed tickets | #29835
| License | MIT
| Doc PR | n/a
<!--
Write a short README entry for your feature/bugfix here (replace this comment block.)
This will help people understand your PR and can be used as a start of the Doc PR.
Additionally:
- 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.
-->
When using the ConfirmationQuestion class to ask a yes / no question,
if the default is true, and the answer regex is '/^y/i', then any
value not starting with [yY] is considered false.
This must include "0", which previously would return true, producing results such as:
```
$ php bin/console do:stuff
$ Do you want to continue? 0 <enter>
$ Ok, continuing!
```
Commits
-------
a0a7400d6f [Console] Fixed#29835: ConfirmationQuestion with default true for answer '0'
This PR was merged into the 3.4 branch.
Discussion
----------
[Debug][ErrorHandler] Preserve our error handler when a logger sets another one
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
When logging errors handled by the `ErrorHandler::handleError()` method, the logger can temporarily set its own custom error handler. This is for example the case of `Monolog` in the `StreamHandler` class (cf ebb804e432/src/Monolog/Handler/StreamHandler.php (L101)).
However, when the previous error handler is restored by the logger, it "skips" the real previous handler (the `ErrorHandler::handleError()` one) in the pile and goes back directly to the one before. I guess this is because the `restore_error_handler()` call is technically done in the error handler itself, so it logically restore it to the one before and not to itself.
Here is an easy small example that shows the PHP behavior : https://3v4l.org/4OZNZ
The only solution I have found to fix it is to set our error handler everytime an error is logged.
Here are the things I discovered while trying to find a cleaner fix :
- Setting the same error handler in the error handler itself doesn't actually add it to the pile. This is why adding a check is useless.
- Checking if the logger modified the error handler is impossible anyway : to get the current error handler, you need to set a new one temporarirly and then revert it. However, when you revert it by calling `restore_error_handler()` you end up having the same problem you are trying to fix...
- Also trying to get the current error handler in the error handler itself will return NULL if it is itself.
Commits
-------
b979fff6b8 [Debug][ErrorHandler] Preserve our error handler when a logger set another one
This PR was merged into the 3.4 branch.
Discussion
----------
[Form] Changed UrlType input type to text when default_protocol is not null
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #29690
| License | MIT
| Doc PR |
replaces #29691
Commits
-------
2791edf1fb [Form] Changed UrlType input type to text when default_protocol is not null
This PR was squashed before being merged into the 3.4 branch (closes#29889).
Discussion
----------
[Serializer] Docblock about throwing exceptions on serializer
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
Most of the serializers can throw a `\Symfony\Component\Serializer\ExceptionInterface`. This makes the docblock in line with that.
Similar to this https://github.com/symfony/symfony/pull/29832
Commits
-------
0b44ad79c6 [Serializer] Docblock about throwing exceptions on serializer
This PR was merged into the 3.4 branch.
Discussion
----------
Enable PHP 7.3 on Travis
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
The bits of #29624 that apply to 3.4.
Commits
-------
335036cf09 Enable PHP 7.3 on Travis
This PR was merged into the 3.4 branch.
Discussion
----------
[Debug][DebugClassLoader] Match more cases for final, deprecated and internal classes / methods extends
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Currently, when there is no comment for a tag and another tag after, the detection does not work. Example :
```php
/**
* @final
*
* @author John
*/
class A {
}
```
AFAIK, those tags must not be in a specific order. That's why we should try to support more cases because we might miss things to report.
Also I do not understand why the regex is not the same for the classes and methods detection. I fixed that too.
I added a lot of cases in the "extends from final class" test and an easy way to add more when needed. Adding them everywhere might be overkill and useless. WDYT ?
I'm considering this as bug fix.
Commits
-------
c3b670a908 [Debug][DebugClassLoader] Match more cases for final, deprecated and internal classes / methods extends
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpKernel] Fix HttpKernel Debug requirement
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
The `LoggerDataCollector` is using the `SilencedErrorContext` class that doesn't exists before Symfony 3.2
Commits
-------
69feb49c0d Fix HttpKernel Debug requirement
This PR was merged into the 3.4 branch.
Discussion
----------
[Form] synchronise the form builder docblock
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
Commits
-------
419d3db86c synchronise the form builder docblock
This PR was merged into the 3.4 branch.
Discussion
----------
[Security] use final annotation to allow mocking the class
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #29946
| License | MIT
| Doc PR |
When the class was initially marked as `final`, it did only contain constants. Since #24337 the `Security` class also contains useful shortcut methods so allowing developers to mock the class in tests looks reasonable to me.
Commits
-------
1da00db247 use final annotation to allow mocking the class
This PR was merged into the 3.4 branch.
Discussion
----------
Grammar fix in exception message
According to https://en.wiktionary.org/wiki/whitespace and https://english.stackexchange.com/questions/25368/what-is-the-plural-form-of-whitespace valid sentences would be:
- Whitespace is ...
- Whitespaces are ...
- Whitespace characters are ...
But this is not correct:
- Whitespace are ...
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Commits
-------
6e279a006b Grammar fix in exception message
This PR was merged into the 3.4 branch.
Discussion
----------
[DependencyInjection] fix tests
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #29928
| License | MIT
| Doc PR |
My changes in #29928 broke the test suite.
Commits
-------
4db0a6e099 fix tests
This PR was merged into the 3.4 branch.
Discussion
----------
[DependencyInjection] forward the parse error to the calling code
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #29891
| License | MIT
| Doc PR |
This change does not fully solve the linked issue, but improves the exception a bit by providing a bit more context.
The error page will no start like this:
Commits
-------
c5c2d31fef forward the parse error to the calling code
This PR was merged into the 3.4 branch.
Discussion
----------
[Security] Do not mix password_*() API with libsodium one
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | n/a
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Argon2IPasswordEncoder uses native `password_hash()` and `password_verify()` functions if the current PHP installation embeds Argon2 support (>=7.2, compiled `--with-password-argon2`).
Otherwise, it fallbacks to the libsodium extension.
This was fine at time the encoder was introduced, but meanwhile libsodium changed the algorithm used by `sodium_crypto_pwhash_str()` which is now argon2id, that goes outside of the scope of the encoder which was designed to deal with `argon2i` only.
Nothing we can do as databases may already contain passwords hashed with argon2id, the encoder must keep validating those.
However, the PHP installation may change as time goes by, and could suddenly embed the Argon2 core integration. In this case, the encoder would use the `password_verify()` function which would fail in case the password was not hashed using argon2i.
This PR prevents it by detecting that argon2id was used, avoiding usage of `password_verify()`.
See https://github.com/jedisct1/libsodium-php/issues/194 and https://github.com/symfony/symfony/issues/28093 for references.
Patch cannot be tested as it is platform dependent.
Side note: I'm currently working on a new implementation for 4.3 that will properly supports argon2id (which has been added to the PHP core sodium integration in 7.3) and argon2i, distinctively.
Commits
-------
d6cfde94b4 [Security] Do not mix usage of password_*() functions and sodium_*() ones
