To be clear, I think I was referring to the security *docs* when I said that, which just need to be written starting with the easiest cases first :)
I like the recipes idea - it could be a set of cookbook articles with the config+code needed to accomplish a few common scenarios. @weaverryan On Apr 20, 2011 4:49 AM, "Christian Schaefer" <[email protected]> wrote: > 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 -- 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
