yeah sorry I extended that a tad.. ;) On 20 Apr., 12:34, ryan weaver <[email protected]> wrote: > 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
