Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #1813
Todo: -
In order to work, add this to the .htaccess:
RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ app.php [QSA,L]
Disabled exception when switching to the user that is already impersonated, exception is now only thrown when trying to switch to a new user.
Added an Excption exception when switching fails because target user does not exist.
Added funtional tests for switching users.
Commits
-------
49a8654 [Security] Use LogoutException for invalid CSRF token in LogoutListener
a96105e [SecurityBundle] Use assertCount() in tests
4837407 [SecurityBundle] Fix execution of functional tests with different names
66722b3 [SecurityBundle] Templating helpers to generate logout URL's with CSRF tokens
aaaa040 [Security] Allow LogoutListener to validate CSRF tokens
b1f545b [Security] Refactor LogoutListener constructor to take options
c48c775 [SecurityBundle] Add functional test for form login with CSRF token
Discussion
----------
[Security] Implement support for CSRF tokens in logout URL's
```
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
```
[](http://travis-ci.org/jmikola/symfony)
This derived from #3006 but properly targeting on the master branch.
This exposes new configuration options to the logout listener to enable CSRF protection, as already exists for the form login listener. The individual commits and their extended messages should suffice for explaining the logical changes of the PR.
In addition to changing LogoutListener, I also created a templating helper to generate logout URL's, which includes a CSRF token if necessary. This may or may not using routing, depending on how the listener is configured since both route names or hard-coded paths are valid options.
Additionally, I added unit tests for LogoutListener and functional tests for both CSRF-enabled form logins and the new logout listener work.
Kudo's to @henrikbjorn for taking the time to document CSRF validation for form login listeners (see [here](http://henrik.bjrnskov.dk/symfony2-cross-site-request-forgery/)). The [Logout CSRF Protection](http://www.yiiframework.com/wiki/190/logout-csrf-protection/) article on the Yii Framework wiki was also helpful in drafting this.
---------------------------------------------------------------------------
by jmikola at 2011-12-31T07:50:31Z
Odd that Travis CI reported a build failure for PHP 5.3.2, but both 5.3 and 5.4 passed: http://travis-ci.org/#!/jmikola/symfony/builds/463356
My local machine passes as well.
---------------------------------------------------------------------------
by jmikola at 2012-02-06T20:05:30Z
@schmittjoh: Please let me know your thoughts on the last commit. I think it would be overkill to add support for another handler service and/or error page just for logout exceptions.
Perhaps as an alternative, we might just want to consider an invalid CSRF token on logout imply a false return value for `LogoutListener::requiresLogout()`. That would sacrifice the ability to handle the error separately (which a 403 response allows us), although we could still add logging (currently done in ExceptionListener).
---------------------------------------------------------------------------
by jmikola at 2012-02-13T17:41:33Z
@schmittjoh: ping
---------------------------------------------------------------------------
by fabpot at 2012-02-14T23:36:22Z
@jmikola: Instead of merging symfony/master, can you rebase?
---------------------------------------------------------------------------
by jmikola at 2012-02-15T00:00:49Z
Will do.
---------------------------------------------------------------------------
by jmikola at 2012-02-15T00:05:48Z
```
[avocado: symfony] logout-csrf (+9/-216) $ git rebase master
First, rewinding head to replay your work on top of it...
Applying: [SecurityBundle] Add functional test for form login with CSRF token
Applying: [Security] Refactor LogoutListener constructor to take options
Applying: [Security] Allow LogoutListener to validate CSRF tokens
Applying: [SecurityBundle] Templating helpers to generate logout URL's with CSRF tokens
Applying: [SecurityBundle] Fix execution of functional tests with different names
Applying: [SecurityBundle] Use assertCount() in tests
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Applying: [Security] Use LogoutException for invalid CSRF token in LogoutListener
[avocado: symfony] logout-csrf (+7) $ git st
# On branch logout-csrf
# Your branch and 'origin/logout-csrf' have diverged,
# and have 223 and 9 different commit(s) each, respectively.
#
nothing to commit (working directory clean)
[avocado: symfony] logout-csrf (+7) $
```
After rebasing, my merge commits disappeared. Is this normal?
---------------------------------------------------------------------------
by stof at 2012-02-15T00:15:07Z
Are you sure they disappeared ? Diverging from the remote branch is logical (you rewrote the history and so changed the commit id) but are you sure it does not have the commits on top of master ? Try ``git log master..logout-scrf``
If your commut are there, you simply need to force the push for the logout-csrf branch (take care to push only this branch during the force push to avoid messing all others as git won't warn you when asking to force)
---------------------------------------------------------------------------
by stof at 2012-02-15T00:17:09Z
ah sorry, you talked only about the merge commit. Yeah it is normal. When reapplying your commits on top of master, the merge commit are not kept as you are reapplying the changes linearly on top of the other branch (and deleting the merge commit was the reason why @fabpot asked you to rebase instead of merging btw)
---------------------------------------------------------------------------
by jmikola at 2012-02-15T00:18:00Z
The merge commits are not present in `git log master..logout-csrf`. Perhaps it used those merge commits when rebasing, as there were definitely conflicts resolved when I originally merged in symfony/master (@fabpot had made his own changes to LogoutListener).
I'll force-push the changes to my PR brange. IIRC, GitHub is smart enough to preserve inline diff comments, provided they were made through the PR and not on the original commits.
---------------------------------------------------------------------------
by jmikola at 2012-02-15T00:19:38Z
That worked well. In the future, I think I'll stick to merging upstream in and then rebasing afterwards. Resolving conflicts is much easier during a merge than interactive rebase.
---------------------------------------------------------------------------
by jmikola at 2012-02-23T18:46:13Z
@fabpot @schmittjoh: Is there anything else I can do for this PR? I believe the exception was the only outstanding question (see: [this comment](https://github.com/symfony/symfony/pull/3007#issuecomment-3835716)).
On the advice of @schmittjoh, this commit adds a LogoutException class for use by LogoutListener if the CSRF token is invalid.
The handling in the Security component's ExceptionListener is modeled after AccessDeniedException, which gets wrapped in an AccessDeniedHttpException in the absence of handler service or error page (I didn't think it was appropriate to re-use those for LogoutException).
This adds several new options to the logout listener, modeled after the form_login listener:
* csrf_parameter
* intention
* csrf_provider
The "csrf_parameter" and "intention" have default values if omitted. By default, "csrf_provider" is empty and CSRF validation is disabled in LogoutListener (preserving BC). If a service ID is given for "csrf_provider", CSRF validation will be enabled. Invalid tokens will result in an InvalidCsrfTokenException being thrown before any logout handlers are invoked.
Commits
-------
4a797df Oracle issues
81d73bb Oracle issues
2316b21 Oracle issues
315bfc4 just update
b20b15b Oracle 10 issues
Discussion
----------
Oracle issues
updated with some adjustments required by stof
---------------------------------------------------------------------------
by fabpot at 2011-12-13T07:24:12Z
@schmittjoh: Can you have a look at this PR?
---------------------------------------------------------------------------
by fabpot at 2011-12-24T08:19:37Z
Can you squash your commit before I merge your PR? Thanks.
As discussed on IRC meetings and in PR #2669 I came up with implementation.
This is option2, I think more elegant.
BC break: yes
Feature addition: no/feature move
Symfony2 test pass: yes
Symfony2 test written: yes
Todo: feedback needed
Commits
-------
1e370d7 typo fix
93d8d44 added some more infos about Config
27efd59 added READMEs for the bridges
34fc866 cosmetic tweaks
d6af3f1 fixed README for Console
6a72b8c added basic README files for all components
Discussion
----------
added basic README files for all components and bridges
heavily based on http://fabien.potencier.org/article/49/what-is-symfony2 and the official Symfony2 documentation
---------------------------------------------------------------------------
by jmikola at 2011/11/03 13:36:07 -0700
Great work. For syntax highlighting on the PHP snippets, you could add "php" after the three backticks.
---------------------------------------------------------------------------
by lsmith77 at 2011/11/03 13:41:29 -0700
done
---------------------------------------------------------------------------
by stealth35 at 2011/11/03 13:49:31 -0700
Nice job, but you also need to add `<?php`
ex :
``` php
<?php
use Symfony\Component\DomCrawler\Crawler;
$crawler = new Crawler();
$crawler->addContent('<html><body><p>Hello World!</p></body></html>');
print $crawler->filter('body > p')->text();
```
---------------------------------------------------------------------------
by lsmith77 at 2011/11/03 13:56:57 -0700
done
---------------------------------------------------------------------------
by ericclemmons at 2011/11/03 19:57:57 -0700
@lsmith77 Well done! This makes consumption of individual components that much easier, *especially* now that `composer.json` files have been added.
---------------------------------------------------------------------------
by lsmith77 at 2011/11/04 01:18:23 -0700
ok .. fixed the issues you mentioned @fabpot
---------------------------------------------------------------------------
by lsmith77 at 2011/11/11 15:00:27 -0800
@fabpot anything else left? seems like an easy merge .. and imho there is considerable benefit for our efforts to spread the word about the components with this PR merged.
---------------------------------------------------------------------------
by drak at 2011/11/11 18:54:13 -0800
You know, it might be a nice idea to put a link to the documentation for each component if there is some at symfony.com
---------------------------------------------------------------------------
by lsmith77 at 2011/11/12 00:59:14 -0800
i did that in some. but i might have missed a few places.
On 12.11.2011, at 03:54, Drak <reply@reply.github.com> wrote:
> You know, it might be a nice idea to put a link to the documentation for each component if there is some at symfony.com
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/2561#issuecomment-2715762
---------------------------------------------------------------------------
by breerly at 2011/11/21 10:28:36 -0800
Pretty excited with this.
---------------------------------------------------------------------------
by dbu at 2011/11/24 00:02:50 -0800
is there anything we can help with to make this ready to be merged?
---------------------------------------------------------------------------
by lsmith77 at 2011/12/18 02:39:23 -0800
@fabpot: seriously .. if you are not going to deliver something "better" and don't provide a reason what is wrong with this .. then its beyond frustrating. i obviously do not claim that these README's are perfect (and certainly still no replacement for proper documentation), but I do claim that in their current form they are a radical step forward to potential users of the Symfony2 components.
This changes helps the common use case of fetching the current user and better complies with the Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter).
Before (still works):
$token = $context->getToken();
$user = $token ? $token->getUser() : null;
After:
$user = $context->getUser();
Commits
-------
7c1cbb9 [Config] Use LoaderResolverInterface for type-hinting
48b084e fixed typo
8ad94fb merged branch hhamon/doctrine_bridge_cs (PR #2775)
240796e [Bridge] [Doctrine] fixed coding conventions.
7cfc392 check for session before trying to authentication details
648fae7 merged branch proofek/domcrawlerform-radiodisabled (PR #2768)
3976b7a [DoctrineBridge] fixed CS
9a04783 merged branch beberlei/SecurityEntityRepositoryIdentifierFix (PR #2765)
3c83b89 [DoctrineBridge] Catch user-error when the identifier is not serialized with the User entity.
36c7d03 Fixed GH-2720 - Fix disabled atrribute handling for radio form elements
Discussion
----------
[Config] Use LoaderResolverInterface for type-hinting
```
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: -
```
I've listed this as a BC break because we're changing the argument type-hint, but I think it's unlikely to affect anyone.
Commits
-------
09562df Update CHANGELOG for 2.1, describe new auth events
cf09c2d added authentication success/failure events
Discussion
----------
[Security] Implementation of a "failed login" event, replaces: PR #1307
As I have to use this feature I have completed its implementation.
Bugfix: no
Feature addition: yes
Symfopny2 tests pass: yes
Replaces/closes PR: #1307
---------------------------------------------------------------------------
by schmittjoh at 2011/11/18 23:57:56 -0800
Usually, this event is used for the wrong reasons (to customize what happens on authentication failure). Can you move your implementation to the AuthenticationProviderManager instead?
see https://github.com/schmittjoh/symfony/blob/master/src/Symfony/Component/Security/Core/Authentication/AuthenticationProviderManager.php#L103
---------------------------------------------------------------------------
by canni at 2011/11/19 06:00:36 -0800
Good point :) I'll not rewrite yours work, I've cherry-picked yours commits. (BTW you added call to `setEventDispatcher` on `security.authentication.manager` to commit related to some different work ;)
---------------------------------------------------------------------------
by fabpot at 2011/11/22 00:12:19 -0800
The new files are missing the LICENSE header. As far as I can see, @schmittjoh fork has a different license from the Symfony one. This needs to be clarified before I can merge this PR.
---------------------------------------------------------------------------
by schmittjoh at 2011/11/22 01:53:09 -0800
No biggy, MIT is fine here.
---------------------------------------------------------------------------
by canni at 2011/11/22 01:57:51 -0800
@fabpot done
---------------------------------------------------------------------------
by fabpot at 2011/11/22 02:22:47 -0800
@canni: Can you update the CHANGELOG file (to reference the changes and the BC breaks -- like the move of KernelEvents for instance).
---------------------------------------------------------------------------
by canni at 2011/11/22 02:40:33 -0800
@fabpot: no problem & done
PS I haven't realized that namespace change of `SecurityEvents` is actually a BC Break, thx for pointing this.
---------------------------------------------------------------------------
by fabpot at 2011/11/22 03:06:17 -0800
@canni: What about keeping a `SecurityEvents` class in the `Http` namespace that just extends the new one. That way, we don't break BC.
---------------------------------------------------------------------------
by canni at 2011/11/22 03:53:01 -0800
@fabpot: that will force us to remove `final` keyword form one of classes.
Maybe we can add new, not extending class e.g.: `GeneralSecurityEvents` or `AuthenticationEvents`, that way we dont break BC and dont introduce confusion in naming?
---------------------------------------------------------------------------
by canni at 2011/11/22 05:53:15 -0800
@fabpot: I've removed the BC break, and squashed schmittjoh commits, to keep things nice and clear.
I've changed Schema.php to not use Restrict on delete/update since
oracle report it as missing keyword. Both restrict and no action on
oracle seems to be redundant and used by default. So the output query
can't use it. I've also changed Schema construct to accept a
SchemaConfig parameter. InitAcl was changed to pass on new Schema a
SchemaConfig generated by SchemaManager, I did that because acl command
was generating names with more than 30 characters and Oracle doesn't
accept, this seems to solve the problem and init:acl works properly.
The Firewall is now executed after the Router. This was needed to have access
to the locale and other request attributes that are set by the Router. This
change implies that all Firewall specific URLs have proper (empty) routes like
`/login_check` and `/logout`.
Commits
-------
f9a65ba Redirect to default_target_path if use_referer is true and the referer is the login_path.
Discussion
----------
Login redirect
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Redirect to default_target_path if use_referer is true and the referer is the login_path.
---------------------------------------------------------------------------
by Seldaek at 2011/10/30 10:52:38 -0700
👍
---------------------------------------------------------------------------
by stealth35 at 2011/10/30 11:04:16 -0700
@snc BC break ?
---------------------------------------------------------------------------
by snc at 2011/10/30 12:11:39 -0700
Well I'm sure it is never intended by a developer to be redirected to the login page after logging in but it could be possible that the controller which displays the login form handles this case, so my change would break it.
* 2.0:
[HttpKernel] fixed Content-Length header when using ESI tags (closes#2623)
[HttpFoundation] added an exception to MimeTypeGuesser::guess() when no guesser are available (closes#2636)
[Security] fixed HttpUtils::checkRequestPath() to not catch all exceptions (closes#2637)
[DoctrineBundle] added missing default parameters, needed to setup and use DBAL without ORM
[Transation] Fix grammar.
[TwigBundle] Fix trace to not show 'in at line' when file/line are empty.
Commits
-------
4d80ebd Remove security token if user was deleted, is disabled or locked to prevent infinite redirect loops to the login path (fixes#1798).
Discussion
----------
[2.1] Fix for issue 1798
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #1798
This is a simplified PR of #2528 for the master branch.
* 2.0:
Added a class to the logs ol element to prevent hiding it when toggling an exception (fixes#2589).
Remove only the security token instead of the session cookie.
Clear session cookie if user was deleted, is disabled or locked to prevent infinite redirect loops to the login path (fixes#1798).
Commits
-------
f9befb6 Remove only the security token instead of the session cookie.
348bccb Clear session cookie if user was deleted, is disabled or locked to prevent infinite redirect loops to the login path (fixes#1798).
Discussion
----------
Fix for issue 1798
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Clear session cookie if user was deleted, is disabled or locked to prevent infinite redirect loops to the login path (fixes#1798).
---------------------------------------------------------------------------
by snc at 2011/11/01 04:01:49 -0700
@stof I have changed the code so that it only removes the token... do we still need any hook support?
---------------------------------------------------------------------------
by stof at 2011/11/01 04:07:17 -0700
well, the hook is for your own use case but it would be for 2.1 only anyway, not for 2.0
---------------------------------------------------------------------------
by snc at 2011/11/07 15:11:52 -0800
Now that #2414 is merged to 2.1, this could be simplified for the master branch...
Commits
-------
ab9caa0 [Security] Check for request's session before attempting writes.
dabff0e [Security] Support removing tokens from a session.
Discussion
----------
[Security] Support removing tokens from a session.
Currently there is no way to remove a session's security token without invalidating the entire session and all its data (the ContextListener will only update the session if a token is non-null and non-anonymous). This patch fixes that.
I consider this a bug and I found no tests to prove otherwise. Let me know if I'm mistaken. Originally mentioned at https://groups.google.com/d/topic/symfony-devs/ojLvh0WUbfo/discussion
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
---------------------------------------------------------------------------
by ms937 at 2011/10/24 05:19:21 -0700
This change looks good to me. In fact I'm using similar patch in my app and it works as intended. Also, several other people requested this on the mailing list. Could someone from Symfony team merge this? Thanks.
Commits
-------
ffa537c replace occurences of "an UserInteface" with "a UserInterface"
Discussion
----------
replace occurences of "an UserInteface" with "a UserInterface"
The locale management does not require sessions anymore.
In the Symfony2 spirit, the locale should be part of your URLs. If this is the case
(via the special _locale request attribute), Symfony will store it in the request
(getLocale()).
This feature is now also configurable/replaceable at will as everything is now managed
by the new LocaleListener event listener.
How to upgrade:
The default locale configuration has been moved from session to the main configuration:
Before:
framework:
session:
default_locale: en
After:
framework:
default_locale: en
Whenever you want to get the current locale, call getLocale() on the request (was on the
session before).
Commits
-------
022a9a7 [Security] Make saving target_path extendible
Discussion
----------
[Security] Make saving target_path extendible
The problem lies in how Security component handles ``target_path`` - the latest request URI is always stored. This can lead to problems in following scenarios:
a) The response type of the request is not HTML (think JSON, XML ..)
b) The URI matches a route that does not listen to HTTP GET
I opened a [PR](https://github.com/symfony/symfony/pull/604) months ago, to partly solve scenario A, which did not make it. Now I am proposing a different solution - user can extend ``ExceptionListener`` and override the logic behind setting the ``target_path`` to match his precise needs.
In my simplified scenario, I would be using:
```
protected function setTargetPath(Request $request)
{
if ($request->isXmlHttpRequest() || 'GET' !== $request->getMethod()) {
return;
}
$request->getSession()->set('_security.target_path', $request->getUri());
}
```
@Seldaek, @schmittjoh, @lsmith77, thoughts?
---------------------------------------------------------------------------
by Seldaek at 2011/09/21 02:37:02 -0700
Seems like a better solution for flexibility's sake. Would be quite awesome if you could add a cookbook entry to symfony/symfony-docs about this, otherwise I'm afraid we'll have to explain it over and over again :)
---------------------------------------------------------------------------
by helmer at 2011/09/21 03:38:57 -0700
[Cookbook](b22c5e666e) entry done. Perhaps though I rushed ahead ..
---------------------------------------------------------------------------
by Seldaek at 2011/09/21 03:52:01 -0700
Thanks. You can already do a pull request against symfony-docs, just reference this pull request in it so it's not merged before this is merged.
Commits
-------
e9d2a67 CS
3a64b08 Search in others user providers when a user is not found in the first user provider and throws the right exception.
Discussion
----------
Chain user provider doesn't search in all user providers
I commit these changes because Chain user provider doesn't search in all user providers.
Example with the Acme/DemoBundle:
// security.yml
...
providers:
chain_provider:
providers: [in_memory, in_memory_extend]
in_memory_extend:
users:
admin2: { password: adminpass2, roles: [ 'ROLE_ADMIN' ] }
in_memory:
users:
user: { password: userpass, roles: [ 'ROLE_USER' ] }
...
firewalls:
...
secured_area:
pattern: ^/demo/secured/
provider: chain_provider OR in_memory_extend
...
We can see these logs :
security.INFO: User "admin2" has been authenticated successfully [] []
security.DEBUG: Write SecurityContext in the session [] []
security.DEBUG: Read SecurityContext from the session [] []
security.DEBUG: Reloading user from user provider. [] []
security.WARNING: Username "admin2" could not be found. [] []
The new code search in others user providers when a user is not found in the first user provider and throws the right exception.
---------------------------------------------------------------------------
by lsmith77 at 2011/08/14 12:20:04 -0700
I wonder if it should be a provider option to continue on a failed user lookup. I can see cases where you really dont want to iterate over all providers and others where you do.
---------------------------------------------------------------------------
by Abhoryo at 2011/08/14 17:27:16 -0700
If someone need a provider like you describe, he can create one.
Here we talk about a chain user provider.
Doc : [using-multiple-user-providers](http://symfony.com/doc/current/book/security.html#using-multiple-user-providers)
We can read in the doc: "The chain_provider will, in turn, try to load the user from both the in_memory and user_db providers."
But its not the case right now.
Commits
-------
09c41d3 [Security] Fixed incorrect merge of two modifications (53f5c23c and 85199677) to AclVoter
Discussion
----------
[Security] Fixed incorrect merge of two modifications to AclVoter
It seems two modifications to `AclVoter` (53f5c23c and 85199677) have been merged incorrectly, leading to a method call on an object that is known to be `null` and a fatal error when running the tests
Commits
-------
eae6a77 fixed wrong case
d0a175bfixes#1659f300ede fixes several bugs
a4f05ac added some tests
Discussion
----------
Http util fixes
Fixes several bugs in the http utils.
Please don't add anymore features without sufficient tests. Especially for the Security\Http namespace, regressions are very likely otherwise.
---------------------------------------------------------------------------
by fabpot at 2011/07/19 22:37:26 -0700
Tests do not pass for me:
There were 2 errors:
1) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testLoginLogoutProcedure with data set #0 ('en')
InvalidArgumentException: The current node list is empty.
.../src/Symfony/Component/DomCrawler/Crawler.php:604
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:16
2) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testLoginLogoutProcedure with data set #1 ('de')
InvalidArgumentException: The current node list is empty.
.../src/Symfony/Component/DomCrawler/Crawler.php:604
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:16
--
There were 4 failures:
1) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testAccessRestrictedResource with data set #0 ('en')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-http://localhost/en/login
+http://localhost/login
.../src/Symfony/Bundle/Securitybundle/Tests/Functional/WebTestCase.php:22
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:38
2) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testAccessRestrictedResource with data set #1 ('de')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-http://localhost/de/login
+http://localhost/login
.../src/Symfony/Bundle/Securitybundle/Tests/Functional/WebTestCase.php:22
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:38
3) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testAccessRestrictedResourceWithForward with data set #0 ('en')
HTTP/1.0 302 Found
Cache-Control: no-cache
Content-Length: 299
Content-Type: text/html; charset=UTF-8
Date: Wed, 20 Jul 2011 05:36:27 GMT
Location: http://localhost/login
Set-Cookie: PHPSESSID=11c9c6a7e7620e13bddef223a5ba46d9; path=/; domain=
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="refresh" content="1;url=http://localhost/login" />
</head>
<body>
Redirecting to <a href="http://localhost/login">http://localhost/login</a>.
</body>
</html>
Failed asserting that <integer:0> matches expected <integer:1>.
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:50
4) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testAccessRestrictedResourceWithForward with data set #1 ('de')
HTTP/1.0 302 Found
Cache-Control: no-cache
Content-Length: 299
Content-Type: text/html; charset=UTF-8
Date: Wed, 20 Jul 2011 05:36:28 GMT
Location: http://localhost/login
Set-Cookie: PHPSESSID=2bbe63786a088471ade3717917f4ba4f; path=/; domain=
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="refresh" content="1;url=http://localhost/login" />
</head>
<body>
Redirecting to <a href="http://localhost/login">http://localhost/login</a>.
</body>
</html>
Failed asserting that <integer:0> matches expected <integer:1>.
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:50
---------------------------------------------------------------------------
by schmittjoh at 2011/07/19 23:47:29 -0700
I fixed a wrong case, but I couldn't reproduce the other errors (tested on Ubuntu).
My guess is that the temporary directory on your machine couldn't be deleted for some reason, and the test runs with the configuration of some of the previous tests.
---------------------------------------------------------------------------
by fabpot at 2011/07/20 00:28:41 -0700
That does not make any difference for me. For instance, in `LocalizedRoutesAsPathTest::testLoginLogoutProcedure()`, the first request to `'/'.$locale.'/login'` returns the following Response:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="refresh" content="1;url=http://localhost/login" />
</head>
<body>
Redirecting to <a href="http://localhost/login">http://localhost/login</a>.
</body>
</html>
---------------------------------------------------------------------------
by schmittjoh at 2011/07/20 00:31:34 -0700
That's weird, did you make sure that the temporary directory does not exist?
``rm -Rf /tmp/StandardFormLogin/``
On Wed, Jul 20, 2011 at 9:28 AM, fabpot <
reply@reply.github.com>wrote:
> That does not make any difference for me. For instance, in
> `LocalizedRoutesAsPathTest::testLoginLogoutProcedure()`, the first request
> to `'/'.$locale.'/login'` returns the following Response:
>
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;
> charset=utf-8" />
> <meta http-equiv="refresh" content="1;url=
> http://localhost/login" />
> </head>
> <body>
> Redirecting to <a href="http://localhost/login">
> http://localhost/login</a>.
> </body>
> </html>
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/1739#issuecomment-1613504
>
---------------------------------------------------------------------------
by fabpot at 2011/07/20 00:33:40 -0700
Yes, I've just checked and the directory does not exist.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/20 00:39:55 -0700
Sorry, I can't reproduce it on Ubuntu and unless someone wants to sponsor me a Mac, there is not much I can do.
Upon unserialize of the acl, the acl is currently set to the id field which should be a string. Currently it passes the acl object into the id field which causes the following error.
Warning: Illegal offset type in isset or empty in Symfony/Component/Security/Acl/Dbal/AclProvider.php line 404
Commits
-------
29e4063 [Security] changed order of checks to check for more specific things first
Discussion
----------
[Security] changed order of checks
Commits
-------
26ff05bfixes#1538
Discussion
----------
fixes#1538
Constructor of Symfony\Component\Security\Acl\Domain\RoleSecurityIdentity
--------------------------------------------------------------------------------------------------------
currently it check if the argument is instance of Symfony\Component\Security\Core\Role\Role by
``if ($role instanceof Role)``
Maybe it should be changed to
``if ($role instanceof RoleInterface)``
Because if we use another Role class which implements RoleInterface
it dosen't work when we check access, it will throw a *NoAceFoundException* when vote
Commits
-------
164aea4 [Security] Add tests for the channel listener
d51cbc0 [Security] Remove useless attribute in basic authentication listener & test it
91e6dc9 [Security] Add tests for the anonymous authentication listener
3c2affb [Security] Update access listener constructor's prototype and add tests
81afd77 [Security] Add tests for the firewall map
aa6ae33 [Security] Remove useless attribute & var in firewall
Discussion
----------
Test security
---------------------------------------------------------------------------
by lsmith77 at 2011/06/29 13:41:07 -0700
@schmittjoh is probably the person to review this change ..
This change removes the need for the {_locale} hack.
Now, all paths in the Security component can be:
* An absolute path (/login)
* An absolute URL (http://symfony.com/login)
* A route name (login)
So, if you want to use a path that includes a global parameter (like _locale),
use a route instead of a path.
Commits
-------
cdf4b6a Checked log levels
a45d3ee Reverted last commit
529381b ControllerNotFound: Changed log level from info to error. Also moved throw exception code block up, to prevent the message from beeing logged multiple times.
7c29e88 Changed log level of "Matched route ..." message from info to debug
dca09fd Changed log level of "Using Controller ..." message from info to debug
Discussion
----------
Log levels
Just wanted to ask if the log level INFO is still correct for these messages?
As there are only four log levels left (DEBUG, INFO, WARNING, ERROR), DEBUG might be the more appropriate level for these messages now.
Let me give an example: An application is logging user actions (maybe to database) in order to assure comprehensibility, e. g. "User %s deleted post %d", "User %s written a message to user %s". These are not warnings of course, so the only suitable log level is INFO.
But they will be thrown together with these very common (at least two per request?) "Using controller..." and "Matched route..." messages when choosing INFO as log level.
---------------------------------------------------------------------------
by Seldaek at 2011/05/24 07:13:18 -0700
Agreed, this stuff is framework debug information.
---------------------------------------------------------------------------
by fabpot at 2011/05/24 08:53:24 -0700
Why do you want to change these two specific ones? The framework uses the INFO level at other places too. Is it a good idea to say that the framework only logs with DEBUG?
---------------------------------------------------------------------------
by stof at 2011/05/24 09:12:53 -0700
Doctrine logs at the INFO level too and I think it is useful to keep it as INFO. Being able to see the queries without having all DEBUG messages of the event dispatcher and security components is useful IMO.
---------------------------------------------------------------------------
by Seldaek at 2011/05/25 02:30:24 -0700
Yeah, that's true, maybe we just need to reintroduce (again, meh:) NOTICE between INFO and WARNING.
@kaiwa Of course the other way could be that you just add your DB handler to the app logger stack. That could be done in a onCoreRequest listener or such, basically you'd have to call `->pushHandler($yourDBHandler)` on the `monolog.logger.app` service. That way your messages will flow to it, but it won't receive noise from the framework stuff since those log on monolog.logger.request and other log channels.
---------------------------------------------------------------------------
by fabpot at 2011/05/25 02:48:26 -0700
@Seldaek: I don't think we need another level. We just need to come up with a standard rules about the usage of each level. Adapted from log4j:
* ERROR: Other runtime errors or unexpected conditions.
* WARN: Use of deprecated APIs, poor use of API, 'almost' errors, other runtime that are undesirable or unexpected, but not necessarily "wrong" (unable to write to the profiler DB, ).
* INFO: Interesting runtime events (security infos like the fact the user is logged-in or not, SQL logs, ...).
* DEBUG: Detailed information on the flow through the system (route match, security flow infos like the fact that a token was found or that remember-me cookie is found, ...).
What do you think?
---------------------------------------------------------------------------
by stloyd at 2011/05/25 02:53:38 -0700
+1 for this standard (also this PR can be merged then), but we should review code for other "wrong" log levels usage (if everyone accept this standard)
---------------------------------------------------------------------------
by fabpot at 2011/05/25 02:55:07 -0700
I won't merge this PR before all occurrences of the logger calls have been reviewed carefully and changed to the right level.
---------------------------------------------------------------------------
by kaiwa at 2011/05/25 02:58:44 -0700
@fabpot: Just noticed these two occurring for every request in my log file. You are right, there are other places where this changes must be applied if we will change the log level.
@stof: Hmm, i see. It is not possible to set the logger separately for each bundle, is it? That maybe would solve the problem. If somebody is interested in seeing the queries, he could set the log handler level to DEBUG for doctrine bundle, but still use INFO for the framwork itself. Plus he could even define a different output file or a completely different handler.
I'm not sure if something like that is possible already (?) or realizable at all... just came into my mind.
---------------------------------------------------------------------------
by Seldaek at 2011/05/25 03:01:07 -0700
Just FYI, from Monolog\Logger (which has CRITICAL and ALERT):
* Debug messages
const DEBUG = 100;
* Messages you usually don't want to see
const INFO = 200;
* Exceptional occurences that are not errors
* This is typically the logging level you want to use
const WARNING = 300;
* Errors
const ERROR = 400;
* Critical conditions (component unavailable, etc.)
const CRITICAL = 500;
* Action must be taken immediately (entire service down)
* Should trigger alert by sms, email, etc.
const ALERT = 550;
The values kind of match http error codes too, 4xx are expected errors that are not really important (404s etc) and 5xx are server errors that you'd better fix ASAP. I'm ok with the descriptions, but I think alert and critical should be included too. I'll probably update Monolog docblocks to match whatever ends up in the docs.
---------------------------------------------------------------------------
by Seldaek at 2011/05/25 03:03:21 -0700
@kaiwa you can do a lot, but not from the default monolog configuration entry, I'm not sure if we can really make that fully configurable without having a giant config mess. Please refer to my [comment above](https://github.com/symfony/symfony/pull/1073#issuecomment-1234316) to see how you could solve it. Maybe @fabpot has an idea how to make this more usable though.
---------------------------------------------------------------------------
by stof at 2011/05/25 03:19:43 -0700
@Seldaek the issue is that the different logging channels are only know in the compiler pass, not in the DI extension. So changing the level in the extension is really hard IMO.
Thus, the handlers are shared between the different logging channels (needed to open the log file only once for instance, or to send a single mail instead of one per channel) and the level is handled in the handlers, not the logger.
I'm +1 for the standard, by adding the distinction between 400 and 500 status calls using ERROR and CRITICAL (which is already the case in the code).
@kaiwa do you have time to review the calls to the logger between DEBUG and INFO or do you prefer I do it ? For instance, the Security component currently logs all message at DEBUG level and some of them should be INFO.
---------------------------------------------------------------------------
by kaiwa at 2011/05/25 04:31:04 -0700
@stof ok i'll do that
---------------------------------------------------------------------------
by kaiwa at 2011/05/25 12:22:51 -0700
Need some help :) I came across `ControllerNameParser::handleControllerNotFoundException()` which leads to redundant log messages currently:
>[2011-05-25 20:53:16] request.INFO: Unable to find controller "AppBaseBundle:Blog" - class "App\BaseBundle\Controller\BlogController" does not exist.
>[2011-05-25 20:53:16] request.ERROR: InvalidArgumentException: Unable to find controller "AppBaseBundle:Blog" - class "App\BaseBundle\Controller\BlogController" does not exist. (uncaught exception) at /home/ruth/symfony3/src/Symfony/Bundle/FrameworkBundle/Controller/ControllerNameParser.php line 87
Is it necessary to call `$this->logger->info($log);` if the InvalidArgumentException will be logged anyway?
---------------------------------------------------------------------------
by stof at 2011/05/25 12:39:22 -0700
Well, the issue is that the ControllerNameParser logs messages and then uses them to throw an exception. I guess the logging call should be removed as it is redundant with the one of the ExceptionListener. @fabpot thoughts ?
---------------------------------------------------------------------------
by kaiwa at 2011/05/27 11:39:25 -0700
I checked all debug, info and log calls. Sometimes it is hard to distinguish between the levels, so it would be great if someone reviews @cdf4b6a. @stof, maybe you want to take a look?
---------------------------------------------------------------------------
by kaiwa at 2011/05/31 12:52:07 -0700
@stof, thanks for your comments. I added some replies above, please let me know your suggestions.
---------------------------------------------------------------------------
by stof at 2011/05/31 14:04:22 -0700
@kaiwa As I said before, all the security logging calls should be DEBUG (most of them) or INFO (the one syaing that authentication succeeded for instance), but not WARN or ERROR as the exception don't go outside the firewall.
* Seldaek/events:
[EventDispatcher] Removed temporary code
[FrameworkBundle] Improved code readability
[FrameworkBundle] Clarified code and fixed regression
Update Core and Security events to latest model
[EventDispatcher] Allow registration of arbitrary callbacks
[EventDispatcher] Remove useless code
[EventDispatcher] Minor memory optimization to getListeners()
[FrameworkBundle] Small optimization, remove some function calls
The main benefit is that in XML/YML files we have common syntax (i.e. core.controller, form.pre_bind) that properly namespaces event names (before: onCoreController was ok, preBind was not).
On the other hand in PHP land we also have namespaced events, CoreEvents::controller, FormEvents::preBind, before it was Events::onCoreController, Events::onPreBind, we now have more context.
This in effect removes the direct link between event name and the method name on the handler.
Any callback can be given as a handler and the event name becomes an arbitrary string. Allowing for easier namespacing (see next commit)
