This PR was merged into the 2.3 branch.
Discussion
----------
removed all @covers annotations
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Some unit tests have a `@covers` PHPUnit annotations. Most of them were added a very long time ago, but since then, we did not use them anymore and the existing ones are not maintained (see #16413). So, I propose to remove them all.
Commits
-------
1e0af36 removed all @covers annotations
This PR was merged into the 2.3 branch.
Discussion
----------
added the new Composer exclude-from-classmap option
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Commits
-------
65bef75 added the new Composer exclude-from-classmap option
This PR was merged into the 2.3 branch.
Discussion
----------
[Security] don't allow to install the split Security packages
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #16134
| License | MIT
| Doc PR |
Currently, you would be able to install the Security component fromm
Symfony 2.3 together with one of the split packages from a higher
Symfony vesion like this:
```json
{
"require": {
"symfony/symfony": "2.3.*",
"symfony/security-core": "~2.7"
}
}
```
However, you will end up with classes being present twice.
This must be reverted after merging up in the `2.7` branch.
Commits
-------
0d14064 don't allow to install the split Security packages
Currently, you would be able to install the Security component fromm
Symfony 2.3 together with one of the split packages from a higher
Symfony vesion like this:
```json
{
"require": {
"symfony/symfony": "2.3.*",
"symfony/security-core": "~2.7"
}
}
```
However, you will end up with classes being present twice.
This must be reverted after merging up in the `2.7` branch.
This PR was squashed before being merged into the 2.3 branch (closes#14842).
Discussion
----------
[Security][bugfix] "Remember me" cookie cleared on logout with custom "secure"/"httponly" config options [1]
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #14822
| License | MIT
| Doc PR | ~
* test now always pass "secure" and "httponly" options, as they are required
* could be considered BC, but [`RememberMeFactory` passes them](https://github.com/symfony/symfony/blob/2.3/src/Symfony/Bundle/SecurityBundle/DependencyInjection/Security/Factory/RememberMeFactory.php#L21), so they should've always been treated as required
* I can squash the commits before merging
* Alternative solution: #14843
Commits
-------
18b1c6a [Security][bugfix] "Remember me" cookie cleared on logout with custom "secure"/"httponly" config options [1]
This PR was merged into the 2.3 branch.
Discussion
----------
[Security] InMemoryUserProvider now concerns whether user's password is changed when refreshing
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
When a user has changed own password, I want to logout any sessions which is authenticated by its user except changer itself.
[DaoAuthenticationManager::checkAuthentication()](https://github.com/symfony/symfony/blob/2.3/src/Symfony/Component/Security/Core/Authentication/Provider/DaoAuthenticationProvider.php#L59) method seems to concern about it.
But, this situation actually never happens because both users that will be passed to this method are always identical in re-authentication.
It's because the token refreshes own user via [ContextListener](https://github.com/symfony/symfony/blob/2.3/src/Symfony/Component/Security/Http/Firewall/ContextListener.php#L90) before re-authentication.
Commits
-------
729902a [Security] InMemoryUserProvider now concerns whether user's password is changed when refreshing
"Fiş" is a correct translation for "token", however "bilet" is also used, I fixed that inconsistency. Moreover, "kimlik bilgileri" is a better translation for "credentials" than "girdiler". "Girdiler" is the translation of "inputs", so I fixed sentences with "credentials". "Hesap engellenmiş" is better than "Hesap devre dışı bırakılmış" for "Account is disabled.". "Digest nonce has expired" can be translated better as "Derleme zaman aşımına uğradı." because "Derleme zaman aşımı gerçekleşti" has a confirmation sense like user requested it to expire and it has expired.
References:
token: http://tureng.com/search/token (3rd entry)
credentials: http://www2.zargan.com/tr/q/credentials-ceviri-nedir (1st entry)
disable: http://tureng.com/search/disable (15th entry)
The `SwitchUserEvent` is triggered in case an account is switched. This works okay while switching to the user, but on exit the `SwitchUserEvent` is triggered again with the original User. That User was not initialized by the provider yet.
load user by UserInterface instead of username
This PR was merged into the 2.3 branch.
Discussion
----------
[2.3] Static Code Analysis for Components
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Static Code Analysis with Php Inspections (EA Extended), no functional changes:
- resolved possible PHP Fatal in \Symfony\Component\BrowserKit\Cookie::__toString
- resolved callable name case mismatches
Commits
-------
9eb2b14 Php Inspections (EA Extended): - resolved possible PHP Fatal in \Symfony\Component\BrowserKit\Cookie::__toString -resolved implicit magic methods calls -resolved callable name case mismatches
- resolved possible PHP Fatal in \Symfony\Component\BrowserKit\Cookie::__toString
-resolved implicit magic methods calls
-resolved callable name case mismatches
This PR was squashed before being merged into the 2.3 branch (closes#14670).
Discussion
----------
[Security] TokenBasedRememberMeServices test to show why encoding username is required
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #14577
| License | MIT
| Doc PR | no
241538d shows that it's not actually tested, 257b796 reimplements it with test.
I can remove the POC commit if it's not needed.
Commits
-------
63a9736 [Security] TokenBasedRememberMeServices test to show why encoding username is required
This PR was squashed before being merged into the 2.3 branch (closes#14678).
Discussion
----------
[Security] AbstractRememberMeServices::encodeCookie() validates cookie parts
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #14577
| License | MIT
| Doc PR | no
`AbstractRememberMeServices::encodeCookie()` guards against `COOKIE_DELIMITER` in `$cookieParts`.
* it would make `AbstractRememberMeServices::cookieDecode()` broken
* all current extending classes do it anyway (see #14670 )
* added tests – it's not a public method, but it is expected to be used by user implementations – as such, it's good to know that it works properly
Commits
-------
464c39a [Security] AbstractRememberMeServices::encodeCookie() validates cookie parts
This PR was merged into the 2.3 branch.
Discussion
----------
[Security][Translation] fixes#14584
| Q | A
| ------------- | ---
| Fixed tickets | #14584
| License | MIT
Some french translations are wrong in the security component.
As #14587 has been closed here's my fix.
Commits
-------
34c780f [Security][Translation] fixes#14584
This PR was merged into the 2.3 branch.
Discussion
----------
CS: Pre incrementation/decrementation should be used if possible
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Fixes provided by new fixer: https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/1113
If this pr is merged I would change the level of the fixer to `symfony`.
Commits
-------
c5123d6 CS: Pre incrementation/decrementation should be used if possible
