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.
* 2.7:
[Finder] Fix recursive filter iterator
Improve the structure of the Finder testsuite
[VarDumper] Fix HtmlDumper constructor calling CliDumper's
[Finder] Handle filtering of recursive iterators and use it to skip looping over excluded directories
Exclude files based on path before applying the sorting
fixed composer.json
[Console] fix phpdoc of DialogHelper
Allowed extensions to inline compiler passes
* 2.3:
[Finder] Fix recursive filter iterator
Improve the structure of the Finder testsuite
Conflicts:
src/Symfony/Component/Finder/Iterator/ExcludeDirectoryFilterIterator.php
src/Symfony/Component/Finder/Tests/FinderTest.php
src/Symfony/Component/Finder/Tests/Iterator/DateRangeFilterIteratorTest.php
This PR was merged into the 2.8 branch.
Discussion
----------
[Translator][FileDumper] deprecated format method in favor of formatCatalogue.
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Fixed tickets | ~
| Tests pass? | yes
| License | MIT
We introduced `formatCatalogue` to allow using options passed to the dump method.
Commits
-------
366879b [Translator][FileDumper] deprecated format method in favor of formatCatalogue.
This PR was merged into the 2.3 branch.
Discussion
----------
[Finder] Fix recursive filter iterator
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #15802
| License | MIT
| Doc PR | -
#15802 was broken because the filters where not propagated to children iterators. This fixes the issue and adds a test case for this situation. The RecursiveIterator implementation is moved from FilterIterator to ExcludeDirectoryFilterIterator. Doing so on other filters is possible but would be a new feature that is not required for fixing the performance issue we had previously.
Commits
-------
cf3019b [Finder] Fix recursive filter iterator
This PR was merged into the 2.8 branch.
Discussion
----------
[WebProfilerBundle] bug #15811 use of twig deprecated sameas test
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #15811
| License | MIT
| Doc PR |
Commits
-------
534c5db bug #15811 use of twig deprecated sameas test
This PR was merged into the 2.3 branch.
Discussion
----------
Improve the structure of the Finder testsuite
| 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
Testing against different adapters is now handled by multiple subclasses of a common test case rather than using data providers. This allows tests to be marked as skipped for unsupported adapters instead of making them disappear from the testsuite.
This will also make it much easier to mark tests for the find-based adapters as legacy ones when deprecating them.
This correspond to changes done by @nicolas-grekas in https://github.com/symfony/symfony/pull/15805, backported to 2.3 and with the data providers removed (his PR was keeping data providers for the adapter but making it return a single adapter all the time, hence the much bigger diff in my PR).
All tests in AbstractFinderTest are just moved from the FinderTest (they are all the tests running against multiple adapters). FinderTest itself runs the PhpAdapter (as this is the logic we want to keep in the finder in 3.0). I also tried to have a PhpFinderTest and keeping FinderTest only with the extra tests, but this would make things harder to merge branches between 2.8 and 3.0 in the future (once we remove other adapter tests) as we could simply keep the AbstractFinderTest in 3.0 for now to ease merging PRs adding new tests for bug fixes.
Commits
-------
20f2d03 Improve the structure of the Finder testsuite
Testing against different adapters is now handled by multiple subclasses
of a common test case rather than using data providers. This allows
tests to be marked as skipped for unsupported adapters instead of making
them disappear from the testsuite.
This PR was merged into the 2.8 branch.
Discussion
----------
Remove minimum width for web profiler content view
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
This removes the min-width on the Web Profiler's content view, to allow for narrower browser windows to render all content without a horizontal scroll bar. I've checked all of the profiler pages, and none of them seem adversely affected by this. (In some cases, certain content winds up being taller because there's less horizontal space, but that's entirely expected and reasonable).
Commits
-------
62dc014 Remove minimum width for web profiler content view
* 2.3:
[Finder] Handle filtering of recursive iterators and use it to skip looping over excluded directories
Exclude files based on path before applying the sorting
[Console] fix phpdoc of DialogHelper
This PR was submitted for the 2.8 branch but it was merged into the 2.3 branch instead (closes#15802).
Discussion
----------
[Finder] Handle filtering of recursive iterators and use it to skip looping over excluded directories
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #5951, #8685
| License | MIT
| Doc PR | -
By implementing RecursiveIterator in FilterIterator, we can make it able to skip children of excluded branches of recursive inner iterators.
We use it immediately for our main target: skip over children of excluded directories in the Finder.
This is a significant performance boost when iterating over big directories, thus the "bugfix" status.
Commits
-------
8c691bd [Finder] Handle filtering of recursive iterators and use it to skip looping over excluded directories
This PR was merged into the 2.8 branch.
Discussion
----------
Validate the extended type for lazy-loaded type extensions
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | not really
| BC breaks? | yes, but only for broken setups
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Symfony 2.1 introduced such validation for form types because a mismatch would actually break the logic (the name is accessed again later).
This was not added for type extensions because in such case, ``getExtendedType`` would actually never be used for extensions loaded by the DI extension (this method is only used inside extensions, and the DI extension relies on the service configuration instead). However, having mismatching values there would make debugging much harder, and can hide mistakes (see #15740 for such a mistake being fixed in the core). It also means that it might be hard to fix usage of deprecated APIs as the code might not contain the same extended type than the one used in the fullstack usage.
Commits
-------
8826d39 Validate the extended type for lazy-loaded type extensions
This PR was merged into the 2.3 branch.
Discussion
----------
[Finder] Exclude files based on path before applying the sorting
| Q | A
| ------------- | ---
| Bug fix? | yes (perf)
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Sorting can be slow, so it is best to applied it after all filtering rules are applied instead of using a bigger list and filtering again after that.
This impacts only people using both the sorting and the name filtering (with ``->names()`` or ``notNames()``)
Commits
-------
e5bf0ab Exclude files based on path before applying the sorting
This PR was merged into the 2.7 branch.
Discussion
----------
Automatically process extensions when they implement CompilerPassInterface
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | todo (if people are in favor of this PR)
Compiler passes are very powerfull, but also quite strange to work with. Especially when you just need a very simple compiler pass (like https://github.com/symfony-cmf/RoutingBundle/blob/master/DependencyInjection/Compiler/SetRouterPass.php). For 3 lines of code, you need to tweak your bundle class and create a new class.
When using the DI component standalone, compiler passes are even harder to work with, as DI extensions can't register them. I believe that's why libraries like Behat make their extensions compiler passes by default.
I think it would be very easy to just implement an interface and have a `compile` method for the simple compiler pass stuff. If a bundle needs multiple compiler passes or need compiler passes to be executed at other times in the compile process, a bundle can use the normal compiler passes. But if it's just one simple thing, like replacing a definition or getting services with a specific tag, I think this method will be very usefull.
Commits
-------
6c50013 Allowed extensions to inline compiler passes
