This makes the app global variable available also when accessing the Twig
environment directly instead of using the TwigEngine.
Conflicts:
src/Symfony/Bridge/Twig/CHANGELOG.md
src/Symfony/Bundle/TwigBundle/Resources/config/twig.xml
src/Symfony/Bundle/TwigBundle/TwigEngine.php
Swapped arguments $groups and $subPath in ExecutionContext::validate and ExecutionContext::validateValue, so they match their interface signatures again.
This PR was merged into the 2.0 branch.
Commits
-------
57edf56 removed wrong routing xsd statement `mixed="true"`
Discussion
----------
removed wrong routing xsd statement `mixed="true"`
mixed="true" means that the element could contain both text and other elements, e.g.
`<requirement key="_locale">text <subelement /></requirement>`
But this wrong and such a definition would not even validate against the scheme as the xsd does not define which elements would be expected inside.
This PR was merged into the 2.0 branch.
Commits
-------
d5623b4 removed unused attribute from routing.xsd
Discussion
----------
removed unused attribute from routing.xsd
This PR was merged into the master branch.
Commits
-------
20dbe47 added annotation
c73cb8a add default for pattern for clarity
ddd8918 make id attribute required
62536e5 refactor to an xsd:group
451dcdc it should be possible to define the defaults, req. and options in any order, just like in YAML
Discussion
----------
improve routing xml scheme
bc break: no
Main points:
- the xml scheme only allowed defaults, requirements and options in this specific order. but the XmlFileLoader does not have the restriction and the YAML definions does not have such an restriction either. this is now fixed. so you can use
```
<requirement key="_locale">en</requirement>
<default key="_controller">Foo</default>
```
Before it had the be first all defaults, then all requirements, then all options.
- make id attribute required
For more changes see commits.
This PR was merged into the master branch.
Commits
-------
373be62 Bugfix for creating cookie on loginSuccess in AbstractRememberMeServices
Discussion
----------
Bugfix for creating cookie on loginSuccess in AbstractRememberMeServices
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #6055
Todo: -
License of the code: MIT
By a mistake setting of new cookies did not work for other RememberMe services than PersistentTokenBasedRememberMeServices
---------------------------------------------------------------------------
by TerjeBr at 2012-12-01T17:28:08Z
Ping. Any feedback on this?
mixed="true" means that the element could contain both text and other elements, e.g.
`<requirement key="_locale">text <subelement /></requirement>`
But this wrong and such a definition would not even validate against the scheme as the xsd does not define which elements would be expected inside.
* 2.1:
replaced magic strings by proper constants
refactored tests for Request
fixed the logic in Request::isSecure() (if the information comes from a source that we trust, don't check other ones)
added a way to configure the X-Forwarded-XXX header names and a way to disable trusting them
fixed algorithm used to determine the trusted client IP
removed the non-standard Client-IP HTTP header
Conflicts:
src/Symfony/Component/HttpFoundation/Tests/RequestTest.php
* 2.0:
replaced magic strings by proper constants
refactored tests for Request
fixed the logic in Request::isSecure() (if the information comes from a source that we trust, don't check other ones)
added a way to configure the X-Forwarded-XXX header names and a way to disable trusting them
fixed algorithm used to determine the trusted client IP
removed the non-standard Client-IP HTTP header
Conflicts:
src/Symfony/Component/HttpFoundation/Request.php
src/Symfony/Component/HttpFoundation/Tests/RequestTest.php
* 2.1: (29 commits)
[DependencyInjection] fixed composer.json
[Validator] Fix typos in validators.ru.xlf
Edited some minor grammar and style errors in russian validation file
Updated Bulgarian translation
[Form] improve error message with a "hasser" hint for PropertyAccessDeniedException
[Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
[Form] simplified a test from previous merge
Update src/Symfony/Component/Form/Extension/Core/Type/FileType.php
fixed CS
Xliff with other node than source or target are ignored
small fix of #5984 when the container param is not set
Filesystem Component mirror symlinked directory fix
[Process][Tests] fixed chainedCommandsOutput tests
fixed CS
Use better default ports in urlRedirectAction
Add tests for urlRedirectAction
info about session namespace
fix upgrade info about locale
Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
Update src/Symfony/Component/DomCrawler/Form.php
...
* 2.0:
[DependencyInjection] fixed composer.json
[Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
fixed CS
small fix of #5984 when the container param is not set
fixed CS
Use better default ports in urlRedirectAction
Add tests for urlRedirectAction
Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
Update src/Symfony/Component/DomCrawler/Form.php
[Security] remove escape charters from username provided by Digest DigestAuthenticationListener
[Security] added test extra for digest authentication
fixed CS
[Security] Fixed digest authentication
[Security] Fixed digest authentication
[SecurityBundle] Convert Http method to uppercase in the config
Use Norm Data instead of Data
Conflicts:
src/Symfony/Bridge/Doctrine/Form/EventListener/MergeCollectionListener.php
src/Symfony/Bundle/FrameworkBundle/Controller/RedirectController.php
src/Symfony/Component/DependencyInjection/composer.json
This PR was merged into the master branch.
Commits
-------
c8e65a2 [FrameworkBundle][Routing] Resolve placeholders in hostnamePattern rules
Discussion
----------
[FrameworkBundle][Routing] Resolve placeholders in hostnamePattern rules
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #6135
License of the code: MIT
Currently the placeholders in the `hostname_pattern` rule are not resolved, so that's why this PR is it for.
---------------------------------------------------------------------------
by nomack84 at 2012-11-28T14:18:02Z
@fabpot Could you please merge this? I really need this fix to be solve.
Thanks!
This PR was merged into the master branch.
Commits
-------
0a380cf [HttpFoundation] disabled Request _method feature by default (should now be explicitely enabled via a call to enableHttpMethodOverride())
Discussion
----------
[HttpFoundation] disabled Request _method feature by default
It should now be explicitely enabled via a call to enableHttpMethodOverride())
This PR was merged into the master branch.
Commits
-------
431d593 [TwigBundle] Renames twig.loader to twig.loader.filesystem.
Discussion
----------
[TwigBundle] Renames twig.loader to twig.loader.filesystem.
In the previous form of twig's service definitions, it was impossible to
use a chain loader correctly because the TwigBundle was registering paths
on the twig.loader service. This patch fixes that by creating a
twig.loader.filesystem definition and an alias twig.loader that points
to twig.loader.filesystem by default.
---------------------------------------------------------------------------
by marcw at 2012-11-27T21:05:53Z
Failed build seems unrelated to this PR.
In the previous form of twig's service definitions, it was impossible to
use a chain loader correctly because the TwigBundle was registering paths
on the twig.loader service. This patch fixes that by creating a
twig.loader.filesystem definition and an alias twig.loader that points
to twig.loader.filesystem by default.
This PR was merged into the 2.1 branch.
Commits
-------
06ee53b [Form] improve error message with a "hasser" hint for PropertyAccessDeniedException
Discussion
----------
[Form] improve error msg w/ a "hasser" hint for PropertyAccessDeniedException
"Hasser" support was added under the 2.1 branch of the Form component
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no, but fails exactly the same as without this fix
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: symfony/symfony-docs#1958
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no, but fails exactly the same as without this fix
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: symfony/symfony-docs#1958
This PR was merged into the master branch.
Commits
-------
1858b96 [Form] Adapted FormValidator to latest changes in the Validator
1f752e8 [DoctrineBridge] Adapted UniqueValidator to latest changes in the Validator
efe42cb [Validator] Refactored the GraphWalker into an implementation of the Visitor design pattern.
Discussion
----------
[Validator] Refactored the Validator for use in Drupal
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: TODO
Drupal wants to use the Symfony Validator component in their next version. I was talking to @fago recently about the changes that we'd need to make and implemented these changes in this PR. I don't want to rush this, but the deadline is tight, since Drupal feature freeze is on December 1st and @fago needs at least a couple of days to integrate the Validator into Drupal.
This PR introduces two significant changes:
* Interfaces were created for all classes that constitute the Validator's API. This is were the PR breaks BC, because `ConstraintValidatorInterface::initialize()` is now type hinted against `ExecutionContextInterface` instead of `ExecutionContext`.
* The graph walker was refactored into an implementation of the Visitor pattern. This way, the validator was decoupled from the structure of the metadata (class → properties and getter methods) and makes it possible to implement a different metadata structure, as is required by the Drupal Entity API.
As a consequence of the API change, custom validation code is now much easier to write, because `ValidatorInterface` and `ExecutionContextInterface` share the following set of methods:
```php
interface ValidatorInterface
{
public function validate($value, $groups = null, $traverse = false, $deep = false);
public function validateValue($value, $constraints, $groups = null);
public function getMetadataFor($value);
}
interface ExecutionContextInterface
{
public function validate($value, $subPath = '', $groups = null, $traverse = false, $deep = false);
public function validateValue($value, $constraints, $subPath = '', $groups = null);
public function getMetadataFor($value);
}
```
No more juggling with property paths, no more fiddling with the graph walker. Just call on the execution context what you'd call on the validator and you're done.
There are two controversial things to discuss and decide (cc @fabpot):
* I moved the `@api` tags of all implementations to the respective interfaces. Is this ok?
* I would like to deprecate `ValidatorInterface::getMetadataFactory()` (tagged as `@api`) in favor of the added `ValidatorInterface::getMetadataFor()`, which offers the exact same functionality, but with a different API and better encapsulation, which makes it easier to maintain for us. We can tag `getMetadataFor()` as `@api`, as I don't expect it to change. Can we do this or should we leave the old method in?
I would like to decide the major issues of this PR until **Sunday November 25th** in order to give @fago enough room for his implementation.
Let me hear your thoughts.
This PR was merged into the master branch.
Commits
-------
d1b5093 Try to make sure cookies get deleted from the TokenProvider when no longer in use
Discussion
----------
Delete cookies from the TokenProvider that is no longer in use
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Todo: -
License of the code: MIT
When the user logs in, or login fails for some reason, the old "remember me" cookie should be deleted from the TokenProvider if you are using the PersistentTokenBasedRememberMeServices.
As the code is now, the token is only deleted on logout.
---------------------------------------------------------------------------
by TerjeBr at 2012-11-20T13:45:54Z
So, anything else that needs to be done before this is merged?
---------------------------------------------------------------------------
by TerjeBr at 2012-11-21T10:30:53Z
Ok, I have corrected the typo in the comment and squashed the commit.
---------------------------------------------------------------------------
by schmittjoh at 2012-11-21T10:36:29Z
btw, ``canceled`` (more American) and ``cancelled`` (more British) are both
correct English forms.
On Wed, Nov 21, 2012 at 11:30 AM, Terje Bråten <notifications@github.com>wrote:
> Ok, I have corrected the typo in the comment and squashed the commit.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/6055#issuecomment-10592112>.
>
>
---------------------------------------------------------------------------
by schmittjoh at 2012-11-21T10:40:24Z
As a side-note have you verified that this does not break the cookie theft protection?
---------------------------------------------------------------------------
by TerjeBr at 2012-11-21T10:51:10Z
Yes, cookie theft protection is still there and is functioning well.
---------------------------------------------------------------------------
by TerjeBr at 2012-11-21T11:14:04Z
I am using this together with the DoctrineTokenProvider in issue #6057 in my own project and done some extensive testing on it.
---------------------------------------------------------------------------
by TerjeBr at 2012-11-23T10:30:34Z
Is this ready to be merged now?
This PR was squashed before being merged into the master branch (closes#6080).
Commits
-------
e477a2e Handle case of static controller method and controllers using magic __call() method
Discussion
----------
Handle case of static controller method and controllers using magic __call() method
Improve collecting controller details for edge cases where:
- controller is array, but contains class name and static method
- method doesn't exist, but is handled by magic __call() method
---------------------------------------------------------------------------
by fabpot at 2012-11-21T08:12:08Z
Can you add some unit tests?
---------------------------------------------------------------------------
by sli-systems at 2012-11-21T22:19:17Z
@pierredup
I disagree with the your comment about is_callable() only working with objects. The PHP docs state that the first argument is a callable, so it can be a string, array, closure, and perhaps more.
The test I added also shows that the code works as is :)
I've thought about your suggestion of adding reflection to look up the location of __call(). However, I think this doesn't really add a lot and only complicates matters. Also, as you can see in the new test, there is also __callStatic() to consider.
The fact that file/line are n/a is correct, because the most typical case will be that __call() and __callStatic() will delegate to some other method that might not even be in the same class/file (a subclass I would expect), IMHO.
@fabpot
Good catch about the '/'. I hope the test is complete enough. Looks more like an exercise on PHP callables than anything else, tho ;)
---------------------------------------------------------------------------
by pierredup at 2012-11-22T04:56:18Z
True that ````is_callable```` takes any callable argument, except in the one specific case where you have a ````__call()```` method, and pass an array with the first paramater as a string.
Take the following example:
class Controller {
public function __call($method, $arguments) {}
}
$controller = array('Controller', 'action');
var_dump(is_callable($controller));
Here ````is_callable($controller)```` will actually return ````false````, where if you have ````$controller = array(new Controller, 'action');```` it would return true.
Of course if you have a ````__callStatic```` method, then it would always return true.
Your tests doesn't seem to cover this use case
---------------------------------------------------------------------------
by sli-systems at 2012-11-22T20:27:05Z
Hmm, maybe. I have to admin that I do not know about this case. OTOH, if is_callable returns false is it really callable then? I would think this more of a PHP bug then?
I think I might have come across this case during coding, but then dismissed it because in that case FilterControllerEvent failed already before the data collector code is reached.
In FilterControllerEvent there is a check on is_callable and a LogicException is thrown if $controller is not callable.
So, is FilterControllerEvent wrong too then?
---------------------------------------------------------------------------
by pierredup at 2012-11-22T20:41:14Z
One would think that if is_callable returns false, then the controller isn't callable, but in the case I mentioned above, the controller is in fact callable. I also thought it was a bug with php, but the php-internals don't seem to think so.
The problem is, if you specify the class as a string, php looks for a static method, even if you have a __call method, it won't be registered.
I will have a look at the FilterControllerEvent to see if this use case applies there as well.
---------------------------------------------------------------------------
by sli-systems at 2012-11-22T20:50:32Z
Rather strange - if that is the case then using is_callable seems pretty pointless and the only way would be to try to execute the controller to find out if it is, in fact, callable...
---------------------------------------------------------------------------
by pierredup at 2012-11-22T20:51:07Z
Okay so it actually seems that the case above isn't callable after all. If the controller is specified as a string, then a static method need to exist. Hence why it works with __callStatic. Only when an instance of the class is specified, will it handle the __call method.
---------------------------------------------------------------------------
by sli-systems at 2012-11-22T20:57:55Z
So the tests are sufficient then?
---------------------------------------------------------------------------
by pierredup at 2012-11-22T20:59:22Z
Yes it is.
This happens when you just assume something without actually testing it :)
Sorry for the hassle
With this refactoring comes a decoupling of the validator from the structure of
the underlying metadata. This way it is possible for Drupal to use the validator
for validating their Entity API by using their own metadata layer, which is not
modeled as classes and properties/getter methods.
This PR was merged into the 2.1 branch.
Commits
-------
82334d2 Force loader to be null or a EntityLoaderInterface
Discussion
----------
Force loader to be null or a EntityLoaderInterface
This PR was merged into the 2.0 branch.
Commits
-------
2d9a6fc Use Norm Data instead of Data
Discussion
----------
[Form] Use Norm Data instead of App Data
This listener is triggered when normalized data are binded.
We have to use $event->getForm()->getNormData() instead of $event->getForm()->getData().
I have made a new FormType having 'entity' as parent and having a NormTransformer. I encountered a problem in MergeCollectionListener when the request is binded.
My commit fix it.
This PR was merged into the 2.1 branch.
Commits
-------
84635bd [Form] allowed no type guesser to be registered
Discussion
----------
[Form] made the factory builder pass null when no type guesser registered
reopened#5422 against 2.1 as it's a bug fix
---------------------------------------------------------------------------
by stof at 2012-10-13T21:23:34Z
@fabpot anything left for this PR ?
---------------------------------------------------------------------------
by fabpot at 2012-10-14T09:41:29Z
@bamarni Can you add some unit tests and also update the FormExtensionInterface interface phpdoc as `getTypeGuesser` can now return `null`? Thanks. ping @bschussek
---------------------------------------------------------------------------
by bamarni at 2012-10-14T17:10:27Z
I've added a few tests covering this.
@fabpot : the phpdoc is already correct, it currently can return null, this only occurs with this convenient class.
---------------------------------------------------------------------------
by bschussek at 2012-10-16T07:43:41Z
This PR breaks FormFactory::createBuilderForProperty(), which expects a guesser to be present. Can you check the component for other uses of the guesser and add a null-check there?
---------------------------------------------------------------------------
by bamarni at 2012-10-16T10:57:54Z
I cannot find other places than the factory (searching for 'getTypeGuesser').
---------------------------------------------------------------------------
by bschussek at 2012-11-08T16:58:37Z
You should also adapt `FormRegistry::getTypeGuesser()` not to build a `FormTypeGuesserChain` if the array of guessers is empty. In that case it will return now `null` (adapt the doc block). We also need a different was of checking if the type guessers have already been parsed in FormRegistry. Otherwise the first if condition in `FormRegistry::getTypeGuesser()` will never become false. You could for example initialize the property `$guesser` to `false` and only set it to `null` after the first run of `getTypeGuesser()`.
---------------------------------------------------------------------------
by bamarni at 2012-11-08T18:40:00Z
good catch I had missed it! I've applied your suggestion in the latest commit. Do you see anything else before I squash?
---------------------------------------------------------------------------
by bschussek at 2012-11-08T18:45:15Z
A test for `FormRegistry::getTypeGuesser()` would of course be awesome.
---------------------------------------------------------------------------
by bamarni at 2012-11-08T18:52:13Z
Then it was already awesome! (see https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Tests/FormRegistryTest.php#L252)
I've also added one for the null case if it's what you meant.
This PR was merged into the master branch.
Commits
-------
e2a50ef [OptionsResolver] fix normalizer without corresponding option
5a53821 [OptionsResolver] fix removing normalizers
Discussion
----------
OptionsResolver: normalizer fix
setNormalizer() -> replace() -> all() would generate an error.
---------------------------------------------------------------------------
by bschussek at 2012-07-29T16:09:20Z
Thank you for the fix! Could you please add a test case?
---------------------------------------------------------------------------
by Tobion at 2012-07-30T15:42:26Z
There is another problem: setNormalizer() (without setting an option) -> all()
I suggest to simply ignore normalizers that have no corresponding option. Do you agree?
---------------------------------------------------------------------------
by Tobion at 2012-07-30T16:19:24Z
On the other hand, one could argue that a normalizer without option should also work like this:
```
$this->options->setNormalizer('foo', function (Options $options) {
return '';
});
$this->assertEquals(array('foo' => ''), $this->options->all());
```
But when having a normalizer that wants a previous value as param, it does not work (because there is none).
---------------------------------------------------------------------------
by stof at 2012-07-30T16:30:34Z
@Tobion according to github, this need to be rebased
---------------------------------------------------------------------------
by bschussek at 2012-07-30T19:16:48Z
I guess setNormalizer() should check whether the option is set and fail otherwise. The second possibility, as you say, is to ignore them in all(). I'd prefer whatever is more efficient.
---------------------------------------------------------------------------
by bschussek at 2012-07-30T19:17:27Z
But setting a normalizer without setting an option, and having that option appear in the final options, does not make sense if you ask me.
---------------------------------------------------------------------------
by Tobion at 2012-07-30T21:23:46Z
Well it could make sense. If you want to override/normalize an option to a given value however it has been overloaded by others or just not overloaded at all. This is what normalizers do. I think its more consistent than the other solutions.
Raising exception in setNormalizer would make the Class dependent on the order you call the methods, e.g. `setNormalizer(); set()` would not work. But the other way round would be ok.
Ignoring some normalizers in `all` would be strange because they are there but not applied under some circumstances.
---------------------------------------------------------------------------
by Tobion at 2012-07-30T21:42:40Z
Added the fix. If you disagree tell me.
---------------------------------------------------------------------------
by bschussek at 2012-08-04T09:30:18Z
> Raising exception in setNormalizer would make the Class dependent on the order you call the methods, e.g. `setNormalizer(); set()` would not work. But the other way round would be ok.
I think this would be a better solution. I dislike if the normalizer magically adds an option that does not exist. This could hide implementation error, e.g. when a refactoring removes an option, but the normalizer is forgotten. Can you throw an exception in this case?
Should we find use cases that rely on this to work, we can soften the behavior and remove the exception.
---------------------------------------------------------------------------
by Tobion at 2012-08-04T15:02:51Z
Well, that would also make it impossible to set a normalizer for on optional option in OptionsResolver.
So `setOptional` + `setNormalizers` would throw an exception which sounds counter-intuitive. Are you sure about that?
---------------------------------------------------------------------------
by Tobion at 2012-08-17T11:47:58Z
ping @bschussek
---------------------------------------------------------------------------
by Tobion at 2012-10-07T22:31:44Z
@bschussek ping
---------------------------------------------------------------------------
by stof at 2012-10-13T18:04:30Z
@bschussek ping
---------------------------------------------------------------------------
by Tobion at 2012-11-08T09:55:15Z
@bschussek please let's get this finished.
this can happen when the config for the router is unset, but this method
does not need to depend on routing. reading an unset config would raise an exception.
This PR was merged into the 2.0 branch.
Commits
-------
64b54dc Use better default ports in urlRedirectAction
64216f2 Add tests for urlRedirectAction
Discussion
----------
Default to current port in urlRedirectAction
I was a bit surprised when I used urlRedirectAction from a non-standard port (8000) it redirected me to port 80. I would argue that the default should be to use the current port instead. This is a simple patch to change that. This should only break in the case someone is relying on the current default to redirect from a non-standard port to the standard port, which should be a really rare case...
---------------------------------------------------------------------------
by Tobion at 2012-11-11T20:29:54Z
The idea is right but the implementation not. Seems this patch is not as "simple" as you said.
When you're on HTTPS and want to redirect to $scheme = HTTP, then it still uses the current HTTPS port which is wrong.
---------------------------------------------------------------------------
by flojon at 2012-11-11T20:36:47Z
Ah, I see the problem. So I guess the correct behavior would be to use the current port if staying with the same scheme or go to standard port if switching scheme. Unless the user has specified a port which will always override...
---------------------------------------------------------------------------
by Tobion at 2012-11-11T20:42:18Z
That would be the best solution that is currently possible but not the best solution that should be possible.
Because if you switch scheme but the other scheme does not use the standard port, it still doesn't work.
Ideally the Request class had an option that allows to define the ports symfony should use for HTTP and HTTPS.
This logic is in RequestContext, but it's not used here.
---------------------------------------------------------------------------
by flojon at 2012-11-11T21:32:55Z
Bummer, I forgot to check if the current port is a standard port...
---------------------------------------------------------------------------
by Tobion at 2012-11-11T21:35:13Z
add some tests
---------------------------------------------------------------------------
by flojon at 2012-11-11T23:28:18Z
Added tests and fixed my previous error
---------------------------------------------------------------------------
by flojon at 2012-11-15T18:25:12Z
@Tobion is there anything else I needed for this?
---------------------------------------------------------------------------
by fabpot at 2012-11-19T12:56:04Z
To be consistent with how we manage HTTP ports elsewhere, I'd rather use the values of the `request_listener.http_port` and `request_listener.https_port`:
```php
if (null === $httpPort) {
$httpPort = $this->container->getParameter('request_listener.http_port');
}
if (null === $httpsPort) {
$httpsPort = $this->container->getParameter('request_listener.https_port');
}
```
This is done in the `security.authentication.retry_entry_point` service and for the `router_listener` listener.
The parameter name is probably not the best one, but that could be changed then in master.
---------------------------------------------------------------------------
by flojon at 2012-11-19T13:49:18Z
@fabpot But then you would need to set that parameter manually right? It wouldn't automatically redirect you to the same port, which was what I wanted to achieve...
Could this be the right order of preference:
If a value was specified in the route use that.
Otherwise use the current port
unless switching scheme then use the parameter value
---------------------------------------------------------------------------
by fabpot at 2012-11-19T13:52:17Z
Your order of preference looks good to me.
---------------------------------------------------------------------------
by flojon at 2012-11-19T19:13:19Z
Man this was more involved than I thought... :)
Changed the logic to use the parameters when not using the current port. Also tried clean up the tests a little bit... Enjoy!
They should normally be initialized anyway in the constructor. But when extending the Route (like in CMF) and using an ORM/ODM to persist them in the DB, the constructor is not called. Then a new property that is not saved like hostnamePattern stays null which in turn makes the RouteCompiler fails as it expects '' instead of null.
This PR was merged into the 2.0 branch.
Commits
-------
f2cbea3 [Security] remove escape charters from username provided by Digest DigestAuthenticationListener
80f6992 [Security] added test extra for digest authentication
d66b03c fixed CS
694697d [Security] Fixed digest authentication
c067586 [Security] Fixed digest authentication
Discussion
----------
Fix digest authentication
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets:
Todo: -
License of the code: MIT
Documentation PR: -
Replaces: #5485
This adds the missing fixes.
My only concerns is the ```\"``` removing.
```\"``` is only needed for the HTTP transport, but keeping them would require to also store the username with the escapes as well.
---------------------------------------------------------------------------
by fabpot at 2012-10-30T11:25:28Z
The digest authentication mechanism is not that widespread due to its limitation. And the transport is not HTTP, I think we are talking about very few cases.
---------------------------------------------------------------------------
by sstok at 2012-10-30T12:49:14Z
Apache seems to remove (ignore) escape characters.
```c
if (auth_line[0] == '=') {
auth_line++;
while (apr_isspace(auth_line[0])) {
auth_line++;
}
vv = 0;
if (auth_line[0] == '\"') { /* quoted string */
auth_line++;
while (auth_line[0] != '\"' && auth_line[0] != '\0') {
if (auth_line[0] == '\\' && auth_line[1] != '\0') {
auth_line++; /* escaped char */
}
value[vv++] = *auth_line++;
}
if (auth_line[0] != '\0') {
auth_line++;
}
}
else { /* token */
while (auth_line[0] != ',' && auth_line[0] != '\0'
&& !apr_isspace(auth_line[0])) {
value[vv++] = *auth_line++;
}
}
value[vv] = '\0';
}
```
But would this change be a BC break for people already using quotes but without a comma and thus they never hit this bug?
The change it self is minimum, just calling ```str_replace('\\\\', '\\', str_replace('\\"', '"', $value))``` when getting the username.
---------------------------------------------------------------------------
by fabpot at 2012-11-13T13:00:12Z
@sstok Doing the same as Apache seems the best option here (just document the BC break).
---------------------------------------------------------------------------
by sstok at 2012-11-15T16:05:00Z
Hopefully I did this correct, but the needed escapes seem correctly removed.
`\"` is changed to `"` `\\` is changed to `\`
`\'` it kept as it is, as this needs no correcting.
@Vincent-Simonin Can you verify please.
---------------------------------------------------------------------------
by Vincent-Simonin at 2012-11-19T09:28:18Z
Authentication didn't work with this configuration :
```
providers:
in_memory:
name: in_memory
users:
te"st: { password: test, roles: [ 'ROLE_USER' ] }
```
`te"st` was set in authentication form's user field.
(Must we also escape `"` in configuration file ?)
Tests were performed with nginx.
---------------------------------------------------------------------------
by sstok at 2012-11-19T09:33:34Z
Yes. YAML escapes using an duplicate quote, like SQL.
```yaml
providers:
in_memory:
name: in_memory
users:
"te""st": { password: test, roles: [ 'ROLE_USER' ] }
```
This PR was squashed before being merged into the master branch (closes#5888).
Commits
-------
2379d86 CS Fixes - Replaced "array of type" by "Type[]" in PHPDoc block
Discussion
----------
CS Fixes - Replaced "array of type" by "Type[]" in PHPDoc block
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no (but tests doesn't pass on master too). See Travis.
License of the code: MIT
Documentation PR: Not Applicable
Status: Finished
To improve support of the eclipse PDT pluggin (for autocompletion), I propose to change the array notation in PHPDoc blocks to match the phpDocumentor notation for "array of type".
Modifications are made for the following components:
- BrowserKit
- ClassLoader
- Config
- Console
- CssSelector
- DependencyInjection
- DomCrawler
- EventDispatcher (no changes)
- Filesystem (no changes)
- Finder
- Form
- HttpFoundation
- HttpKernel
- Locale
- OptionResolver (no changes)
- Process (no changes)
- Routing (no changes)
- Serializer (no changes)
- Templating
- Translation
- Validator
- Yaml (no changes)
- Security
- Stopwatch (no changes)
See Proposal https://github.com/symfony/symfony/pull/5852
---------------------------------------------------------------------------
by pborreli at 2012-11-01T15:19:27Z
will you make a PR for each component ? why not only one PR with one commit for each component instead ?
---------------------------------------------------------------------------
by raziel057 at 2012-11-01T15:32:39Z
Ok, I'm going try to do it.
---------------------------------------------------------------------------
by raziel057 at 2012-11-01T16:12:56Z
I would like to rename my branch from COMPONENT_Form to changes-phpdoc (as all modifications would be commited in only one branch), so I tried to execute the following command but I have an error.
git remote rename COMPONENT_Form changes-phpdoc
error: Could not rename config section 'remote.COMPONENT_Form' to 'remote.changes-phpdoc'
Do you know how to do it?
---------------------------------------------------------------------------
by pborreli at 2012-11-01T16:14:26Z
don't rename it, you will have to close and make another PR which is useless here, just edit the title.
---------------------------------------------------------------------------
by stof at 2012-11-01T16:16:17Z
and ``git remote rename`` is about renaming a remote repo, not a branch
---------------------------------------------------------------------------
by raziel057 at 2012-11-03T11:36:02Z
Is it normal that all my commit are duplicated? I would like just update my master and merge with my branch.
---------------------------------------------------------------------------
by fabpot at 2012-11-06T10:22:55Z
@raziel057 Can you rebase on master? That should fix your problem.
---------------------------------------------------------------------------
by fabpot at 2012-11-09T13:28:53Z
@raziel057 Can you finish this PR?
---------------------------------------------------------------------------
by Tobion at 2012-11-09T13:34:45Z
I'll do it for the routing component this evening because I know it by heart. ^^
---------------------------------------------------------------------------
by raziel057 at 2012-11-09T15:06:26Z
@Tobion ok Thanks!
@fabpot Yes, I will try to finish it this week end.
---------------------------------------------------------------------------
by raziel057 at 2012-11-11T13:04:07Z
@Tobion Did you already change PHPDoc in the Routing component?
---------------------------------------------------------------------------
by Tobion at 2012-11-11T15:21:18Z
@raziel057 Yes I'm working on it.
---------------------------------------------------------------------------
by Tobion at 2012-11-12T15:16:31Z
@raziel057 Done. See #5994
This PR was merged into the 2.0 branch.
Commits
-------
32dc31e [SecurityBundle] Convert Http method to uppercase in the config
Discussion
----------
[SecurityBundle] Convert Http method to uppercase in the config
This is not striclty required as method names would be converted to uppercase by the matcher after #5988.
However I think it is better to always use uppercase for http method names.
The config UT has also been improved as part of this PR.
This is good to propagate to 2.1 & 2.2 also.
This PR was merged into the master branch.
Commits
-------
824a0f3 [Routing] compatibility with older PCRE (pre 8)
Discussion
----------
[Routing] compatibility with older PCRE (pre 8)
#6062 for master
This PR was merged into the 2.1 branch.
Commits
-------
1daefa5 [Routing] made it compatible with older PCRE version (pre 8)
Discussion
----------
[Routing] compatibility with older PCRE version (pre 8)
fixes#4093
Ok I changed my mind about this issue.
1. I figured more people are affected than I thought and CentOS is stubborn.
2. Symfony still uses the old regex style `?P<param>` in several other components. So also doing so in the routing makes it more consistent.
3. Even if it's definitely not good to use an over 6 year old PCRE version with a recent PHP version, we can still try to provide the best experience. It doesn't mean we support outdated software stacks of custom PHP compilations as we won't and cannot specifically test against it.
@fabpot: I will do a seperate PR on master when you merged this because the code changed alot in master so it cannot easily be merged I guess. I will also convert the symfony requirement for PCRE in the requirements check to a recommendation.
This PR was merged into the master branch.
Commits
-------
acbb393 Renamed variable for consistency
Discussion
----------
[SecurityBundle] Renamed variable for consistency
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
This PR was merged into the master branch.
Commits
-------
966e7d6 [DI] removed unneeded is_object() calls
Discussion
----------
[DI] removed unneeded is_object() calls
I searched through all of symfony for occurences of the coding style `(is_object($value) && $value instanceof Object)` with a regex like `is_object\(\$[a-zA-z0-9]+\) && \$[a-zA-z0-9]+ instanceof `.
The `is_object` calls are not needed in this case. Only the DI component made such duplicate checks.
