I think this makes sense based on what was discussed at the SF Live hack day. I realize I threw my support behind removing class parameters, too, but with respect to security component, I want to make sure there will be a way for MessageDigestPasswordEncoder to remain configurable.
This is one of the trouble points I brought up at the hack day (Security bundle doesn't make it easy to implement your own salt-merging strategy), so OpenSky is currently dependent on overriding the class parameter to inject our replacement. I realize the best practice is to replacing services entirely rather than tweaking internal XML config parameters (be it class names or altering arguments manually), so my solution is not proper in the long-term. But until the Security config is versatile enough to allow a drop-in MessageDigestPasswordEncoder service, I think that class parameter should stick around :) On Wed, Mar 16, 2011 at 10:43 AM, Fabien Potencier < [email protected]> wrote: > Hi all, > > This morning, I was working on making some Security things more > configurable, and so I have removed some SC (Service Container) parameters > to replace them with default values in the related Configuration class. For > instance: > > > https://github.com/symfony/symfony/commit/b638cf07a5865ed93efda9cf223d79897ee78277 > > On the one hand, it makes things "cleaner" and more consistent as > everything is now managed/configured via the Configuration class (you cannot > change things directly via a parameter anymore). > > But on the other hand, it also makes some service definitions tied to the > SC extension (as you can see, security.authentication.listener.basic for > instance has 2 blank arguments that must be replaced by the extension). > > So, before the change, it was possible to "just" include the XML file and > get working services (configured via the change of some parameter values if > needed). After the change, the XML file only makes sense when used with the > extension and the configuration classes. > > As I will make some more similar changes elsewhere in the framework, I just > want to be sure that everybody is on the same page here. On a side note, as > we have also decided to remove most class parameters, it means that the core > framework will barely use parameters. > > Any thoughts? > > Fabien > > -- > Fabien Potencier > Sensio CEO - Symfony lead developer > sensiolabs.com | symfony.com | fabien.potencier.org > Tél: <%2B33%201%2040%2099%2080%2080>+33 1 40 99 80 80 > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- jeremy mikola -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
