* 2.2:
[PropertyAccess] added moves to pluralMap
[Security] fixed issue where authentication listeners clear unrelated tokens
fix issue #8499 modelChoiceList call getPrimaryKey on a non object
[DependencyInjection] Add exception for service name not dumpable in PHP
Conflicts:
src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php
src/Symfony/Component/DependencyInjection/Tests/Dumper/PhpDumperTest.php
src/Symfony/Component/Security/Tests/Http/Firewall/BasicAuthenticationListenerTest.php
This commit fixes an issue where authentication listeners clear all security tokens in case of authentication failure.
This behavior makes it impossible to combine certain authentication mechanisms, notably x509 with form-based login.
* 2.2:
Fix finding ACLs from ObjectIdentity's with different types
[HttpKernel] tweaked previous merge
#7531: [HttpKernel][Config] FileLocator adds NULL as global resource path
Fix autocompletion of command names when namespaces conflict
Fix timeout in Process::stop method
fixed CS
Round stream_select fifth argument up.
Fix Process timeout
[HttpKernel] Remove args from 5.3 stack traces to avoid filling log files, fixes#7259
bumped Symfony version to 2.2.2-DEV
updated VERSION for 2.2.1
updated CHANGELOG for 2.2.1
Fixed phpdoc blocks to show that $uri can be passed as a string or ControllerReference (rather than just as a string)
[HttpFoundation] Fixed copy pasted comment from FlashBag in AttributeBag
[FrameworkBundle] fixed the discovery of the PHPUnit configuration file when using aggregate options like in -vc app/ (closes#7562)
[WebProfilerBundle] removed next pointer class in a template
fix overwriting of request's locale if attribute _locale is missing
Conflicts:
src/Symfony/Component/HttpKernel/Debug/ErrorHandler.php
src/Symfony/Component/HttpKernel/EventListener/LocaleListener.php
src/Symfony/Component/HttpKernel/Kernel.php
* 2.1:
Add a public modifier to an interface method
[HttpRequest] fixes Request::getLanguages() bug
[HttpCache] added a test (cached content should be kept after purging)
[DoctrineBridge] Fixed non-utf-8 recognition
[Security] fixed HttpUtils class tests
* 2.1:
sub-requests are now created with the same class as their parent
[FrameworkBundle] removed BC break
[FrameworkBundle] changed temp kernel name in cache:clear
[DoctrineBridge] Avoids blob values to be logged by doctrine
[Security] use current request attributes to generate redirect url?
[Validator] fix showing wrong max file size for upload errors
[TwigBridge] removed double var initialization (refs #7344)
[2.1][TwigBridge] Fixes Issue #7342 in TwigBridge
[FrameworkBundle] fixed cahe:clear command's warmup
[TwigBridge] now enter/leave scope on Twig_Node_Module
[TwigBridge] fixed fixed scope & trans_default_domain node visitor
[TwigBridge] fixed non probant tests & added new one
[BrowserKit] added ability to ignored malformed set-cookie header
[Translation] removed wriong 'use'
[Translation] added xliff loader/dumper with resname support
[TwigBridge] fixes
Conflicts:
src/Symfony/Bundle/FrameworkBundle/HttpKernel.php
src/Symfony/Component/Security/Http/HttpUtils.php
src/Symfony/Component/Translation/Loader/XliffFileLoader.php
src/Symfony/Component/Translation/Tests/Loader/XliffFileLoaderTest.php
* 2.1:
added support for the X-Forwarded-For header (closes#6982, closes#7000)
fixed the IP address in HttpCache when calling the backend
[EventDispatcher] Added assertion.
[EventDispathcer] Fix removeListener
[DependencyInjection] Add clone for resources which were introduced in 2.1
[DependencyInjection] Allow frozen containers to be dumped to graphviz
Fix 'undefined index' error, when entering scope recursively
[Security] fixed session creation on login (closes#7011)
Add dot character `.` to legal mime subtype regular expression
[HttpFoundation] fixed the creation of sub-requests under some circumstancies (closes#6923, closes#6936)
* 2.1:
[HttpKernel] fixed the creation of the Profiler directory
[Security] fixed session creation when none is needed (closes#6917)
[FrameworkBundle] removed obsolete comment (see 2e356c1)
This PR was merged into the master branch.
Commits
-------
67d7423 Remove use of deprecated HttpKernel LoggerInterface
dca4528 [HttpKernel] Extend psr/log's NullLogger class
1e5a890 [Monolog] Mark old non-PSR3 methods as deprecated
91a86f8 [HttpKernel][Monolog] Add PSR-3 support to the LoggerInterface
Discussion
----------
[HttpKernel][MonologBridge] PSR-3 support
This enables PSR-3 support and monolog 1.3+. The first commit is the main part. The rest deals with deprecation of short-hand methods (warn/err/crit/emerg) that are fully expanded in PSR-3 (warning/error/critical/emergency).
The downside of deprecating them is that for bundles it's a bit harder to support older and newer versions. If that is too much of a hassle you can drop that for now and cherry pick the first commit.
The upside is that it forces people to move towards PSR-3 compatible stuff, which means eventually we could completely drop the LoggerInterface from the framework. In any case I think the documentation should only mention the `Psr\Log\LoggerInterface` and people should start hinting against that. The change should be done in core as well I suppose.
Anyway I wanted to throw this out there as it is to get feedback.
---------------------------------------------------------------------------
by stof at 2013-01-09T09:15:15Z
@Seldaek I also think you should change the typehint to use the PSR LoggerInterface in all classes using the logger
---------------------------------------------------------------------------
by Seldaek at 2013-01-09T09:54:55Z
OK updated according to all the feedback. I tested it in an app and it still seems to work so there shouldn't be any major issues.
---------------------------------------------------------------------------
by Seldaek at 2013-01-09T09:59:55Z
@fabpot if you merge please merge also the bundle PR, otherwise it won't be possible to update without conflict.
---------------------------------------------------------------------------
by frosas at 2013-01-10T14:59:20Z
I'm trying to understand why a `composer update` of a Symfony 2.1.* resulted in a fatal error. Shouldn't a stable version don't break like this?
As @olaurendeau points, why Symfony depends 1.* instead of 1.2.*? Or why Monolog 1.3 breaks its public interface (EDIT: I'm not sure about it)? Or why isn't this PR being merged (into branch 2.1) at the same time Monolog 1.3 is released?
Please, understand I'm not looking for who to blame, it's just I want to know if this situation is unexpected or if otherwise a `composer update` on a stable branch is not as innocent as it seems.
---------------------------------------------------------------------------
by stof at 2013-01-10T15:06:51Z
@frosas it cannot be merged into 2.1 as it is a BC break. The 2.1 branch has been updated to forbid Monolog 1.3 already
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T15:11:58Z
@frosas you can blame me for releasing as 1.3.0 and not 2.0, but technically for monolog this isn't really a BC break, I just added an interface. The problem is due to the way it's used in symfony, it ended up as a fatal error. In any case the situation is now sorted out I think.
---------------------------------------------------------------------------
by frosas at 2013-01-10T15:26:43Z
@stof now I see this `>=1.0,<1.3-dev` change in the 2.1 branch. Now, shouldn't a new (2.1.7) version be released for all of us not in the dev minimum-stability?
@Seldaek then do you see feasible to rely only in X.Y.* versions to avoid this kind of errors?
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T15:45:22Z
@frosas relying on X.Y.* is painful because you always need to wait until someone updates the constraint to get the new version. Of course using ~1.3 like in this PR means if I fuck up and break BC people will update to it, but that's a less likely occurrence than the alternative I think, so I would rather not use X.Y.*
---------------------------------------------------------------------------
by frosas at 2013-01-10T15:50:50Z
@Seldaek you are right about this, but I was thinking more in changing it only for the stable versions. EDIT: I mean, how often do you need a new feature in a branch you only apply fixes to?
---------------------------------------------------------------------------
by stof at 2013-01-10T15:57:32Z
@frosas Monolog and Symfony have separate release cycles. Foorcing Symfony users to use an old version of Monolog until they update to a new version of Symfony whereas the newer Monolog is compatible is a bad idea. Thus, as Monolog keeps BC, it does not maintain bugfix releases for all older versions (just like Twig does too). So it would also forbid you to get the fixes done in newer Monolog versions.
The incompatibility between Symfony 2.1 LoggerInterface and PSR-3 (whereas they expect exactly the same behavior and signature for methods with the same name) is unfortunate and is the reason why we get some issues here.
---------------------------------------------------------------------------
by frosas at 2013-01-10T16:21:06Z
@stof I appreciate you prefer to allow newer versions at the price of having to be constantly monitoring its changes to avoid breaks.
Another similar but safer strategy would be to stick to X.Y.* versions and upgrade to X.Y+1.* once the new version integration is tested, but I understand this is discutible in projects as close to Symfony as Monolog.
Returning to the issue, what do you say to release this 2.1.7 version? Or is it only me who is having issues here?
---------------------------------------------------------------------------
by stof at 2013-01-10T16:26:20Z
@frosas a minor release should not break BC when following smeantic versionning (Symfony warned about the fact it is not strictly followed for the first releases of 2.x). But as far as monolog is concerned, 1.3 is BC with 1.2.
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T16:49:55Z
@frosas sorry I didn't get you still had the problem. I tagged a 2.1.7 of monologbundle which hopefully fixes your issue.
This PR was merged into the master branch.
Commits
-------
73db84f [Security] Move translations file to 'security' domain
324703a [Security] Switch to English messages as message keys
aa74769 [Security] Fix CS + unreachable code
2d7a7ba [Security] Fix `AuthenticationException` serialization
50d5724 [Security] Introduced `UsernameNotFoundException#get/setUsername`
39da27a [Security] Removed `get/setExtraInformation`, added `get/set(Token|User)`
837ae15 [Security] Add note about changed constructor to changelog
d6c57cf [FrameworkBundle] Register security exception translations
d7129b9 [Security] Fix exception constructors called in `UserChecker`
0038fbb [Security] Add initial translations for AccountStatusException childs
50e2cfc [Security] Add custom `getMessageKey` AccountStatusException childs
1147977 [Security] Fix InsufficientAuthenticationException constructor calls
79430b8 [Security] Fix AuthenticationServiceException constructor calls
42cced4 [Security] Fix AuthenticationException constructor calls
963a1d7 [Security] Add initial translations for the exceptions
ed6eed4 [Security] Add `getMessageKey` and `getMessageData` to auth exceptions
694c47c [Security] Change signature of `AuthenticationException` to match `\Exception`
Discussion
----------
[2.2][Security] AuthenticationException enhancements
Bug fix: semi
Feature addition: yes
Backwards compatibility break: yes
Symfony2 tests pass: [](http://travis-ci.org/asm89/symfony)
Fixes the following tickets: #837
License of the code: MIT
This PR adds the functionality discussed in #837 and changes the constructor of the `AuthenticationException` to match that of `\Exception`. This PR will allow developers to show a translated (save) authentication exception message to the user. :)
*Todo:*
- Add some functional test to check that the exceptions can indeed be translated?
- Get feedback on the current English messages
---------------------------------------------------------------------------
by asm89 at 2012-07-15T14:04:11Z
ping @schmittjoh
---------------------------------------------------------------------------
by schmittjoh at 2012-07-15T14:57:32Z
Looks good to me.
While you are at the exceptions, I think we can also get rid of the "extra information" thing and replace it by explicit getters/setters. Mostly that will mean adding set/getToken, set/getUser, set/getUsername. Bundles might add custom exceptions which have other data. This will make it a bit more useful and predictable.
---------------------------------------------------------------------------
by asm89 at 2012-07-15T15:40:45Z
@schmittjoh I removed the `get/setExtraInformation` and added the more explicit getters/setters as you suggested.
---------------------------------------------------------------------------
by asm89 at 2012-07-15T19:33:15Z
@fabpot Did you reschedule this for 2.2? Why? It was originally a 2.1 ticket. I think it is an important one because at the moment there is no reliable way to show users the cause of an `AuthenticationException` without the threat of exposing sensitive information. This issue has been around for a while, see the original issue this PR refers to, or for example [this TODO comment in FOSUB](https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Controller/SecurityController.php#L37).
The PR itself is ready to merge now. My only question that remains is about whether the actual translations should be functional tested?
---------------------------------------------------------------------------
by fabpot at 2012-07-15T19:43:19Z
We need to stop at some point. If not, we never release anything. beta3 was scheduled for today and I don't plan any other one before the first RC and I won't have time to review this PR next week. So, if you, @schmittjoh, @vicb, @stof, and a few other core devs "validate" this PR, I might consider merging it before 2.1.
---------------------------------------------------------------------------
by asm89 at 2012-07-15T19:46:09Z
@fabpot I totally agree with your point of view. I just have been trying to pickup some security issues that were still open. :)
---------------------------------------------------------------------------
by stof at 2012-07-15T19:50:29Z
This looks good to me
---------------------------------------------------------------------------
by asm89 at 2012-08-12T09:06:24Z
Since the beta period is over I assume the window was missed to get this security related PR in 2.1. If I have feedback from @fabpot I'll still try to make it mergeable asap though.
---------------------------------------------------------------------------
by fabpot at 2012-08-13T10:10:32Z
@asm89 This would indeed be considered for merging in 2.2.
---------------------------------------------------------------------------
by Antek88 at 2012-10-03T10:30:46Z
+1
---------------------------------------------------------------------------
by stof at 2012-10-04T21:27:15Z
@asm89 could you rebase this PR ? It conflicts with master
---------------------------------------------------------------------------
by fabpot at 2012-10-05T17:16:44Z
What's the status of this PR? @asm89 Have you taken all the feedback into account?
---------------------------------------------------------------------------
by stof at 2012-10-13T17:48:48Z
@asm89 ping
---------------------------------------------------------------------------
by fabpot at 2012-10-29T09:48:40Z
@asm89 If you don't have time, I can finish the work on this PR, but can you just tell me what's left?
---------------------------------------------------------------------------
by asm89 at 2012-10-29T10:02:22Z
I can pick this up, but I have two outstanding questions:
- One about adding `::create()`? https://github.com/symfony/symfony/pull/4935#discussion_r1358297
- And what is the final verdict on the messages? https://github.com/symfony/symfony/pull/4935#discussion_r1165701 The initial idea was that the exception itself have an exception message which is plain english and informative for the developer. If you want to display the 'safe' user messages you have the optional dependency on the translator. There is a comparison made with the Validator component, but in my opinion that's a different case because the violations always contain the message directed at the user and have no plain english message for the developer. Apart from that the Validator component contains it's own code for replacing `{{ }}` variables in messages (duplication? not as flexible as the translator). Concluding I'd opt for: optional dependency on translator component if you want to show 'safe' user messages + message keys.
@schmittjoh Any things to add?
---------------------------------------------------------------------------
by schmittjoh at 2012-10-29T10:14:09Z
Message keys sound good to me. I wouldn't add the ``create`` method for now.
On Mon, Oct 29, 2012 at 11:02 AM, Alexander <notifications@github.com>wrote:
> I can pick this up, but I have two outstanding questions:
>
> - One about adding ::create()? symfony/symfony#4935<https://github.com/symfony/symfony/issues/4935#discussion_r1358297>
> - And what is the final verdict on the messages? symfony/symfony#4935<https://github.com/symfony/symfony/issues/4935#discussion_r1165701>The initial idea was that the exception itself have an exception message
> which is plain english and informative for the developer. If you want to
> display the 'safe' user messages you have the optional dependency on the
> translator. There is a comparison made with the Validator component, but in
> my opinion that's a different case because the violations always contain
> the message directed at the user and have no plain english message for the
> developer. Apart from that the Validator component contains it's own code
> for replacing {{ }} variables in messages (duplication? not as
> flexible as the translator). Concluding I'd opt for: optional dependency on
> translator component if you want to show 'safe' user messages + message
> keys.
>
> @schmittjoh <https://github.com/schmittjoh> Any things to add?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/4935#issuecomment-9861016>.
>
>
---------------------------------------------------------------------------
by fabpot at 2012-10-29T10:27:37Z
As I said in the discussion about the translations, I'm -1 for the message keys to be consistent with how we manage translations everywhere else in the framework.
---------------------------------------------------------------------------
by stof at 2012-10-29T10:30:50Z
@fabpot When we changed the English translation for the validation errors in 2.1, we had to tag the commit as a BC rbeak as it was changing the source for all other translations. And if you look at the state of the files now, you will see that we are *not* using the English as source anymore in some places as some validation errors have a pluralized translation but the source has not been changed.
So I think using a key is more future-proof.
---------------------------------------------------------------------------
by asm89 at 2012-10-30T19:44:49Z
Any final decision on this? On one hand I have @stof and @schmittjoh +1 on message keys, on the other @fabpot -1. I guess it's your call @fabpot.
Edit: also @vicb seemed to be +1 on message keys earlier on.
---------------------------------------------------------------------------
by drak at 2012-11-01T20:19:00Z
I am also -1, I agree with @fabpot
---------------------------------------------------------------------------
by asm89 at 2012-11-12T09:38:51Z
@fabpot Can you please give a definite answer on this? I personally think @stof and @vicb have good points to do message keys, but with all these different people +1 and -1'ing the PR I'm lost on what it should actually do.
---------------------------------------------------------------------------
by asm89 at 2012-11-14T09:59:06Z
ping @fabpot
---------------------------------------------------------------------------
by asm89 at 2012-11-26T10:01:27Z
ping @fabpot We talked about this in Berlin. Any final thoughts on the PR? :) One idea was to do message keys + opt depend on the translator component if you want to use them, or use your own implementation.
---------------------------------------------------------------------------
by fabpot at 2012-11-26T14:01:37Z
The conclusion is: keep using plain English.
On Mon, Nov 26, 2012 at 11:01 AM, Alexander <notifications@github.com>wrote:
> ping @fabpot <https://github.com/fabpot> We talked about this in Berlin.
> Any final thoughts on the PR? :) One idea was to do message keys + opt
> depend on the translator component if you want to use them, or use your own
> implementation.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/4935#issuecomment-10709997>.
>
>
---------------------------------------------------------------------------
by Inori at 2012-11-26T15:00:22Z
is this final? if not, then +1 for message keys
---------------------------------------------------------------------------
by vicb at 2012-11-27T22:33:47Z
@fabpot I can't understand why we keep discussing this for months as this implementation use *both* keys and plain Englis, ie using keys is optional ( if it was not it would not be an issue according to #6129)
---------------------------------------------------------------------------
by asm89 at 2013-01-02T21:43:46Z
@fabpot @vicb I'll rebase this PR, fix the comments and refactor the message keys to use plain English + {{ }} syntax for the placeholders.
---------------------------------------------------------------------------
by asm89 at 2013-01-07T15:00:58Z
@fabpot If I fix this tonight, will it make the beta?
---------------------------------------------------------------------------
by fabpot at 2013-01-07T15:53:00Z
yes, definitely.
---------------------------------------------------------------------------
by asm89 at 2013-01-07T20:13:38Z
@fabpot I switched the implementation to English messages instead of message keys and fixed the final comments + rebased. Anything you want me to do after this?
Still happy with `getMessageKey()`?
* 2.1:
[Console] Fix style escaping parsing
[Console] Make style formatter matching less greedy to avoid having to escape when not needed
[Bundle] [FrameworkBundle] fixed indentation in esi.xml services file.
[Component] [Security] fixed PSR-2 coding violation in ClassUtilsTest class.
[Form] Fixed EntityChoiceList when loading objects with negative integer IDs
[TwigBundle] There is no CSS visibility of display, should be visible instead
[Form] corrected source node for a Danish translation
[DependencyInjection] fixed a bug where the strict flag on references were lost (closes#6607)
[HttpFoundation] Check if required shell functions for `FileBinaryMimeTypeGuesser` are not disabled
[CssSelector] added css selector with empty string
[HttpFoundation] Docblock for Request::isXmlHttpRequest() now points to Wikipedia
[DependencyInjection] refactored code to avoid logic duplication
[Form] Deleted references in FormBuilder::getFormConfig() to improve performance
[HttpFoundation] Update docblock for non-working method
Conflicts:
src/Symfony/Bundle/TwigBundle/Resources/views/Exception/trace.html.twig
src/Symfony/Bundle/TwigBundle/Resources/views/Exception/traces.html.twig
* 2.1: (24 commits)
updated license year
Update src/Symfony/Component/HttpFoundation/Response.php
[Form] Fixed inheritance of "error_bubbling" in RepeatedType
[Form] Fixed DateType when used with the intl extension disabled.
[HttpFoundation] fix return types and handling of zero in Response
[HttpFoundation] better fix for non-parseable Expires header date
Fixed missing plural message in portuguese validator
Fix Expires when the header is -1
[DoctrineBridge] Allowing memcache port to be 0 to support memcache unix domain sockets.
[Console] fixed unitialized properties (closes#5935)
[Process] Prevented test from failing when pcntl extension is not enabled.
Revert "[DoctrineBridge] Improved performance of the EntityType when used with the "query_builder" option"
[Form] Fixed failing tests for DateTimeToStringTransformer.
[Locale] Fixed the StubLocaleTest for ICU versions lower than 4.8.
[Bundle] [FrameworkBundle] fixed typo in phpdoc of the SessionListener.
[Form] Fixed test regression introduced in #6440
[Tests] Fix namespaces
Fixed php doc of GenericEvent::__construct
HttpUtils must handle RequestMatcher too
use preferred_choices in favor of preferred_query
...
Conflicts:
src/Symfony/Bridge/Propel1/Form/ChoiceList/ModelChoiceList.php
* 2.1:
fixed CS
fixed CS
[Security] fixed path info encoding (closes#6040, closes#5695)
[HttpFoundation] added some tests for the previous merge and removed dead code (closes#6037)
Improved Cache-Control header when no-cache is sent
removed unneeded comment
Fix to allow null values in labels array
fix date in changelog
removed the Travis icon (as this is not stable enough -- many false positive, closes#6186)
Revert "merged branch gajdaw/finder_splfileinfo_fpassthu (PR #4751)" (closes#6224)
Fixed a typo
Fixed: HeaderBag::parseCacheControl() not parsing quoted zero correctly
[Form] Fix const inside an anonymous function
[Config] Loader::import must return imported data
[DoctrineBridge] Fixed caching in DoctrineType when "choices" or "preferred_choices" is passed
[Form] Fixed the default value of "format" in DateType to DateType::DEFAULT_FORMAT if "widget" is not "single_text"
[HttpFoundation] fixed a small regression
Conflicts:
src/Symfony/Component/HttpFoundation/Tests/Session/Storage/Handler/MongoDbSessionHandlerTest.php
