[Security] Various CS + doc fixes
[Security] Exception when authentication failure/success handlers do not return a response
[Security] Add authors + fix docblock
The charset was configurable in a configuration file but it never worked:
framework:
charset: ISO-8859-1
Now, like for the cache and log dirs, you can configure the charset by
overriding the getCharset() method in the app kernel:
public function getCharset()
{
return 'ISO-8859-1';
}
Commits
-------
aa055df [Composer] Stwitch to composer vendors management
Discussion
----------
[Composer] Stwitch to composer vendors management
Bug fix: no
Feature addition: yes
Backwards compatibility break: No?
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
[](http://travis-ci.org/canni/symfony)
This speeds up Travis CI builds to `~2 min` also makes vendor management
a lot easier.
---------------------------------------------------------------------------
by fabpot at 2012-02-09T06:24:24Z
I'm -1 on this change. The `vendors.php` script is *only* for people working on the core so that we can run the unit tests. So, we need the flexibility to test on many different versions of the code and having the repository here is kind of mandatory.
---------------------------------------------------------------------------
by Seldaek at 2012-02-09T08:15:28Z
You can `composer install --dev` to get proper clones. I'm not really pro or against, just saying it's an option.
---------------------------------------------------------------------------
by canni at 2012-02-09T08:28:54Z
@fabpot I understand yours point, but from my view transferring the whole git structure of *vendors* is little pointless IMO (especially in Travis env)
but I think I can make this change optional, so Travis and anyone that prefer to, can use `composer` an with old functionality available.
(There will be almost no duplication, as anyway we're updating `composer.json`)
---------------------------------------------------------------------------
by canni at 2012-02-09T09:20:17Z
@fabpot I've enabled both behaviors, everything will work regardless of using `composer` or `vendors.php` this lets the developer decide what to use
---------------------------------------------------------------------------
by drak at 2012-02-16T12:05:28Z
Since there is a `--dev` option in Composer then I think this is a good idea. You could also add composer.phar to the repo bin directory.
---------------------------------------------------------------------------
by henrikbjorn at 2012-02-16T12:06:55Z
`--dev` have been renamed to `--prefer-source`
---------------------------------------------------------------------------
by canni at 2012-02-16T12:22:01Z
@fabpot any chance to consider this merge? If not, this PR can be closed.
---------------------------------------------------------------------------
by henrikbjorn at 2012-02-16T12:25:51Z
@canni This is the goal eventually. But i think we need composer to be a bit more stable in its solver.
---------------------------------------------------------------------------
by francoispluchino at 2012-02-16T12:39:24Z
👍
---------------------------------------------------------------------------
by jmikola at 2012-04-06T18:19:27Z
@fabpot: Is this PR still off the table, or are you reconsidering it with the `--prefer-source` option? I was just running symfony unit tests, and attempted to install deps with composer as I thought this PR or another like it had recently been merged to core. It wasn't :)
Admittedly, it's a downside that vendor libs, even if git repositories, will be nestled within the `.composer/` directory.
---------------------------------------------------------------------------
by drak at 2012-04-07T00:20:33Z
@canni This PR needs to be rebased and reviewed because of the changed tests directory (there is no longer a central `tests/` folder).
---------------------------------------------------------------------------
by canni at 2012-04-07T06:34:28Z
Hey,
will do after a weekend.
canni
Użytkownik Drak <reply@reply.github.com> napisał:
>@canni This PR needs to be rebased and reviewed because of the changed tests directory (there is no longer a central `tests/` folder).
>
>---
>Reply to this email directly or view it on GitHub:
>https://github.com/symfony/symfony/pull/3291#issuecomment-5004750
---------------------------------------------------------------------------
by canni at 2012-04-08T19:02:03Z
@drak done.
Bug fix: no
Feature addition: yes
Backwards compatibility break: ?
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This speeds up Travis CI builds to `~2 min` also makes vendor management
a lot easier.
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.
Using "securitybundletest" as the default environment for the functional test's kernel causes a PHP fatal error redeclaring the class "appSecuritybundletestDebugProjectContainer" when multiple tests (with unique names) are executed. In lieu of forcing tests to specify their own environment explicitly, we can simply append the test name into the environment.
Note: this bug may be related to PHPUnit executing multiple tests within the same process.
As each firewall is configured, its logout listener (if any) will be registered with the LogoutUrlHelper service. In a template, this helper may be used to generate relative or absolute URL's to a particular firewall's logout path. A CSRF token will be appended to the URL as necessary.
The Twig extension composes the helper service to avoid code duplication (see: #2999).
* 2.0:
fixed functional tests so that the cache/logs are specific to one version of Symfony (to avoid weird side effects)
[FrameworkBundle] Prove client insulation and non-insulation works in session tests.
[FrameworkBundle] Add tests to prove functional testing works with simultaneous clients.
[FrameworkBundle] Small changes to test setup.
[DoctrineBundle] Fixed incorrectly shown params
[SwiftmailerBundle] fixed the send email command when the queue does not extends Swift_ConfigurableSpool
* 2.0:
[FrameworkBundle] Added functional tests.
[Form] Added missing use statements (closes#2880)
[Console] Improve input definition output for Boolean defaults
[SecurityBundle] Changed environment to something unique.
2879: missing space between catch and the brace
#2688: Entities are generated in wrong folder (doctrine:generate:entities Namespace)
[TwigBundle] Fix the exception message escaping
Commits
-------
d2195cc Fixed phpdoc and updated the changelog
9e41ff4 [SecurityBundle] Added a validation rule
b107a3f [SecurityBundle] Refactored the configuration
633f0e9 [DoctrineBundle] Moved the entity provider service to DoctrineBundle
74732dc [SecurityBundle] Added a way to extend the providers section of the config
Discussion
----------
[WIP][SecurityBundle] Added a way to extend the providers section of the config
Bug fix: no
Feature addition: yes
BC break: <del>no (for now)</del> yes
Tests pass: yes
This adds a way to extend the ``providers`` section of the security config so that other bundles can hook their stuff into it. An example is available in DoctrineBundle which is now responsible to handle the entity provider (<del>needs some cleanup as the service definition is still in SecurityBundle currently</del>). This will allow PropelBundle to provide a ``propel:`` provider for instance.
In order to keep BC with the existing configuration for the in-memory and the chain providers, I had to allow using a prototyped node instead of forcing using an array node with childrens. This introduces some issues:
- impossible to validate easily that a provider uses only one setup as prototyped node always have a default value (the empty array)
- the ``getFixableKey`` method is needed in the interface to support the XML format by pluralizing the name.
Here is my non-BC proposal for the configuration to clean this:
```yaml
security:
providers:
first:
memory: # BC break here by adding a level before the users
users:
joe: { password: foobar, roles: ROLE_USER }
john: { password: foobarbaz, roles: ROLE_USER }
second:
entity: # this one is BC
class: Acme\DemoBundle\Entity\User
third:
id: my_custom_provider # also BC
fourth:
chain: # BC break by adding a level before the providers
providers: [first, second, third]
```
What do you think about it ? Do we need to keep the BC in the config of the bundle or no ?
Btw note that the way to register the factories used by the firewall section should be refactored using the new way to provide extension points in the extensions (as done here) instead of relying on the end user to register factories, which would probably mean a BC break anyway.
---------------------------------------------------------------------------
by lsmith77 at 2011/10/23 09:19:23 -0700
i don't think we should keep BC. the security config is complex as is .. having BC stuff in there will just make it even harder and confusing.
---------------------------------------------------------------------------
by willdurand at 2011/10/23 09:41:25 -0700
Is the security component tagged with `@api` ?
So basically, we just have to create a factory (`ModelFactory` for instance) and to register it in the `security` extension, right ? Seems quite simple to extend and much better than the hardcoded version…
Why did you call the method to pluralize a key `getFixableKey` ?
---------------------------------------------------------------------------
by beberlei at 2011/10/23 14:48:26 -0700
Changing security config will introduce risk for users. We should avoid that
---------------------------------------------------------------------------
by stof at 2011/10/23 15:34:47 -0700
@beberlei as the config is validated, it will simply give them an exception during the loading of the config if they don't update their config.
---------------------------------------------------------------------------
by stof at 2011/10/24 01:01:42 -0700
@schmittjoh @fabpot Could you give your mind about it ?
---------------------------------------------------------------------------
by stof at 2011/10/31 17:08:12 -0700
@fabpot @schmittjoh ping
---------------------------------------------------------------------------
by stof at 2011/11/11 14:08:18 -0800
I updated the PR by implementing my proposal as the latest IRC meeting agreed that we don't need to keep the BC for this change. This allows to add the validation rule now.
---------------------------------------------------------------------------
by stof at 2011/11/16 11:16:06 -0800
@fabpot ping
---------------------------------------------------------------------------
by fabpot at 2011/11/16 22:29:05 -0800
@stof: Before merging, you must also add information about how to upgrade in the CHANGELOG-2.1.md file.
---------------------------------------------------------------------------
by stof at 2011/11/17 00:01:23 -0800
@fabpot done
The configuration is now cleaner by avoiding using prototyped nodes
as additional keys. This is a BC break for existing providers.
- MemoryProvider:
security:
providers:
my_provider:
memory: # this level has been added
users:
# ...
- ChainProvider:
security:
providers:
my_provider:
chain: # This level has been added
providers:
# ...
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).
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
-------
5b0f1da [HttpKernel] made WebTestCase methods static
Discussion
----------
[HttpKernel] made WebTestCase methods static
This makes it possible to load fixture data in `::setUpBeforeClass()` which makes tests run much faster.
Also, `createClient()` is not protected instead of public; I'm not sure why it was public in the first place.
The main tree doesn't actually process the factories (that's done in an earlier step), so it doesn't actually need their real value. It does, however, need to *not* throw an exception when they're present. An alternative to this approach would be to call ignoreExtraKeys() on the root node of the main tree, but this would allow extra keys to be passed in at the root level, which I thought was a less-desirable solution.
Note that this commit removes the built-in support for MongoDB user providers.
This code can be moved back in once there is a stable release for MongoDB, but
for now you have to set-up that user provider just like you would set-up any
custom user provider:
security:
providers:
document_provider:
id: my.mongo.provider
How to upgrade?
For XML configuration files:
* All extensions should now use the config tag (this is just a convention as
the YAML configurations files do not use it anymore):
* The previous change means that the doctrine and security bundles now are
wrapped under a main "config" tag:
<doctrine:config>
<doctrine:orm />
<doctrine:dbal />
</doctrine:config>
<security:config>
<security:acl />
...
</security:config>
For YAML configuration files:
* The main keys have been renamed as follows:
* assetic:config -> assetic
* app:config -> framework
* webprofiler:config -> web_profiler
* doctrine_odm.mongodb -> doctrine_mongo_db
* doctrine:orm -> doctrine: { orm: ... }
* doctrine:dbal -> doctrine: { dbal: ... }
* security:config -> security
* security:acl -> security: { acl: ... }
* twig.config -> twig
* zend.config -> zend
This reverts commit f53080860a.
Revert "[Router] config fixes"
This reverts commit 51beecc6f2.
Revert "moved duplicated files to a new Config component"
This reverts commit a8ec9b27f0.
The merging is done in three steps:
1. Normalization:
=================
All passed config arrays will be transformed into the same structure
regardless of what format they come from.
2. Merging:
===========
This is the step when the actual merging is performed. Starting at the root
the configs will be passed along the tree until a node has no children, or
the merging of sub-paths of the current node has been specifically disabled.
Left-Side Right-Side Merge Result
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-nothing- array Right-Side will be taken.
scalar scalar Right-Side will be taken.
array false Right-Side will be taken if ->canBeUnset()
was called on the array node.
false array Right-Side will be taken.
array array Each value in the array will be passed to
the specific child node, or the prototype
node (whatever is present).
3. Finalization:
================
The normalized, and merged config will be passed through the config tree to
perform final validation on the submitted values, and set default values
where this has been requested.
You can influence this process in various ways, here is a list with some examples.
All of these methods must be called on the node on which they should be applied.
* isRequired(): Node must be present in at least one config file.
* requiresAtLeastOneElement(): PrototypeNode must have at least one element.
* treatNullLike($value): Replaces null with $value during normalization.
* treatTrueLike($value): Same as above just for true
* treatFalseLike($value): Same as above just for false
* defaultValue($value): Sets a default value for this node (only for scalars)
* addDefaultsIfNotSet(): Whether to add default values of an array which has not
been defined in any configuration file.
* disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined
in one configuration file, subsequent
configurations may only overwrite these.
* fixXmlConfig($key, $plural = null): Transforms XML config into same structure
as YAML, and PHP configurations.
* useAttributeAsKey($name): Defines which XML attribute to use as array key.
* cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All
configuration for this path must be defined in the same
configuration file.
* cannotBeEmpty(): If value is set, it must be non-empty.
* canBeUnset(): If array values should be unset if false is specified.
Architecture:
=============
The configuration consists basically out of two different sets of classes.
1. Builder classes: These classes provide the fluent interface and
are used to construct the config tree.
2. Node classes: These classes contain the actual logic for normalization,
merging, and finalizing configurations.
After you have added all the metadata to your builders, the call to
->buildTree() will convert this metadata to actual node classes. Most of the
time, you will not have to interact with the config nodes directly, but will
delegate this to the Processor class which will call the respective methods
on the config node classes.
