hi all, The security system as it is now is overcomplex and underdocumented. It seems to be very flexible to cover a whole lot of use cases (maybe even all there can be?). But that flexibility comes with the price of being complex.
I think the next step should be to create recipes on a per-use-case base with individual documentation of that use case, its integration into the system and out of the box configurations that can be used at will. I believe that the number of classes will not be a huge drawback as they won't be used if your use case doesn't require them. Or that's what I think should be the case. But! Especially in bigger companies or working for big client projects the internal requirements to security (legacy SSO services, custom made active directory structures, SAP authentication, whatever..) will not follow any standard for which there can be such a standard recipe. In such a case you're pretty much on your own. On your own with the security system that is. There's a lot of opportunity to get things wrong by just not understanding the concepts (yes plural). If you ask Java developers when faced with Spring Security you will often hear how they dreaded touching it as it demands a lot of attention to understand. I'm not saying it is not possible to achieve pretty much anything with the security system but the learning curve is steep. What is missing imho are some class and flow diagrams for a better understanding. As I discovered some classes are only executed when populating the cache, some classes/methods are never called except from generated classes and of course everything is completely decoupled (good for flexibility) which makes it hard to understand the relations between classes (bad for understandability). I personally think it is vital for the future of Symfony2 to smoothen the edges by simplifying things like this chunky security system and making it more usable. If that requires a new concept or just some more complete documentation I can not say at the moment. But I see a danger that people will go for easier options and might end up prefering i.e. Silex over Symfony even if their use case would require Symfony. To put it in the words of Ryan Weaver: the Symfony2 security system needs (much) more love. /Christian On 20 Apr., 11:21, Jordi Boggiano <[email protected]> wrote: > On 20.04.2011 10:50, Matthias Nothhaft wrote: > > > - "loadByUsername()": Is this really intended to load a user by > > username? Or can username also be the ID ? Loading users by username > > will make the system instable if users have the possibility to change > > their usernames. > > As far as I know, username can be anything, and I can't believe that we > still didn't fix this naming issue. It's been discussed many times, a > really clear and appropriate term could not be found, but what's sure is > that username is confusing. > > Cheers > > -- > Jordi Boggiano > @seldaek ::http://seld.be/ -- 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
