* 2.7:
Fix undefined array $server
Fix bug in windows detection
[ProxyManager] Tmp fix composer reqs issue in ZF
Add missing exclusions from phpunit.xml.dist
[Serializer] ObjectNormalizer: don't serialize static methods and props
Fix the server variables in the router_*.php files
[Validator] Allow an empty path with a non empty fragment or a query
The following change adds support for Armenian pluralization.
[2.3][Process] fix Proccess run with pts enabled
Conflicts:
composer.json
src/Symfony/Bridge/ProxyManager/composer.json
src/Symfony/Component/Security/phpunit.xml.dist
This PR was squashed before being merged into the 2.8 branch (closes#16395).
Discussion
----------
checkCredentials() force it to be an affirmative yes!
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no (because 2.8 isn't released)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
This changes `GuardAuthenticatorInterface::checkCredentials()`: you now *must* return true in order for authentication to pass.
Before: You could do nothing (i.e. return null) and authentication would pass. You threw an AuthenticationException to cause a failure.
New: You *must* return `true` for authentication to pass. If you do nothing, we will throw a `BadCredentialsException` on your behalf. You can still throw your own exception.
This was a suggestion at symfony_live to make things more secure. I think it makes sense.
Commits
-------
14acadd checkCredentials() force it to be an affirmative yes!
* 2.7:
added the new Composer exclude-from-classmap option
added the new Composer exclude-from-classmap option
fix expected argument type docblock
Set back libxml settings after testings.
fixed Twig deprecation notices
This PR was merged into the 2.8 branch.
Discussion
----------
Updating behavior to not continue after an authenticator has set the response
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/14673/files#r40492765
| License | MIT
| Doc PR | n/a
This mirrors the behavior in core: *if* a listener sets a response (on success or failure),
then the other listeners are not called. But if a response is *not* set
(which is sometimes the case for success, like in BasicAuthenticationListener),
then the other listeners are called, and can even fail.
It's all a bit of an edge-case, as only one authenticator (like authentication listener) would normally be doing any work on a request, but I think matching the other listeners (since I'm not aware of anyone having issues with its behavior) is best.
Commits
-------
5fa2684 Making all "debug" messages use the debug router
f403444 Updating behavior to not continue after an authenticator has set the response
This PR was merged into the 2.8 branch.
Discussion
----------
Making GuardTokenInterface extend TokenInterface
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #15884
| License | MIT
| Doc PR | n/a
See #15884
Commits
-------
7f04fbb Making GuardTokenInterface extend TokenInterface
This mirrors the behavior in core: *if* a listener sets a response (on success or failure),
then the other listeners are not called. But if a response is *not* set
(which is sometimes the case for success, like in BasicAuthenticationListener),
then the other listeners are called, and can even fail.
This is quite technical. As you can see in the provider, the method is called
sometimes when the User changes, and so the token becomes de-authenticated (e.g.
someone else changes the password between requests).
In practice, the user should be unauthenticated. Using the anonymous token did this,
but throwing an AccountStatusException seems like a better idea. It needs to be an
AccountStatusException because the ExceptionListener from the Firewall looks for exceptions
of this class and logs the user out when they are found (because this is their purpose).
This solution is a copy of what AbstractAuthenticationListener does. Scenario:
1) Login
2) Go back to the log in page
3) Put in a bad user/pass
You *should* still be logged in after a failed attempt. This commit gives that behavior.
This looks like a subjective change (one more method, but the method implementations are
simpler), but it wasn't. The problem was that the UserChecker checkPreAuth should happen
*after* we get the user, but *before* the credentials are checked, and that wasn't possible
before this change. Now it is.
Here is the flow:
A) You login using guard and are given a PostAuthGuardToken
B) Your user changes between requests - AbstractToken::setUser() and hasUserChanged() - which
results in the Token becoming "not authenticated"
C) Something calls out to the security system, which then passes the no-longer-authed
token back into the AuthenticationProviderManager
D) Because the PostauthGuardToken implements GuardTokenInterface, the provider responds
to it. But, seeing that this is a no-longer-authed PostAuthGuardToken, it returns
an AnonymousToken, which triggers logout
The reason is that the GuardAuthenticationProvider *must* respond to *all* tokens
created by the system - both "pre auth" and "post auth" tokens. The reason is that
if a "post auth" token becomes not authenticated (e.g. because the user changes between
requests), then it may be passed to the provider system. If no providers respond (which
was the case before this commit), then AuthenticationProviderManager throws an exception.
The next commit will properly handle these "post auth" + "no-longer-authenticated" tokens,
which should cause a log out.
