| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 2.8:
fixed obsolete getMock() usage
fixed obsolete getMock() usage
[WebProfilerBundle] Display multiple HTTP headers in WDT
do not remove the Twig ExceptionController service
removed obsolete condition
do not try to register incomplete definitions
|
| | | |
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 3.0:
[travis] Fix deps=low/high builds
fixed CS
skip test with current phpunit bridge
Fix for #19183 to add support for new PHP MongoDB extension in sessions.
[Console] Fix for block() padding formatting after #19189
[Security][Guard] check if session exist before using it
bumped Symfony version to 3.0.9
updated VERSION for 3.0.8
updated CHANGELOG for 3.0.8
bumped Symfony version to 2.8.9
updated VERSION for 2.8.8
updated CHANGELOG for 2.8.8
bumped Symfony version to 2.7.16
updated VERSION for 2.7.15
update CONTRIBUTORS for 2.7.15
updated CHANGELOG for 2.7.15
Fix some lowest deps
Fixed typos in the expectedException annotations
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
src/Symfony/Component/Security/Guard/Authenticator/AbstractFormLoginAuthenticator.php
|
| | | |
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the response (weaverryan)
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 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.
|
| |/
|
|
| |
out a test field
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
redundant
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
an interface
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.
|
|
|
authentication system
|
