I actually haven't seen the AclBundle (looks like it came out last month). We were using Zend_Acl with a homemade bundle a few months ago, but gave that up after deciding we didn't need ACL at the time. I have seen SecurityBundle and DoctrineUserBundle, but they were a bit too new to start using when we commenced development. Both look very promising though, and I hope they become staples once Fabien decides how Symfony2 will implement security (SecurityBundle might be a great project to pick up).
We have a hard enough time keeping our production app up to date with the Symfony master, so I'm a bit hesitant to migrate over to community bundles until Symfony's feature-set is a bit more are locked down :) On Sep 14, 5:41 am, Florian <[email protected]> wrote: > You surely are aware of some Security bundles already available for > Symfony2: > > http://github.com/pminnieur/SecurityBundle > > http://github.com/IamPersistent/AclBundle > > A mixin of those with DoctrineUserBundle could give good results. > > On 13 sep, 20:04, Jeremy Mikola <[email protected]> wrote: > > > We're using CAS with Symfony2 right now > > (usinghttp://github.com/jmikola/SimpleCASBundle), > > but I would love to turn that into a simple mechanism/handler to use > > with a proper Symfony2 security bundle. At the moment, each action > > needs to start off by explicitly requiring authentication. > > > For backend/CMS tools, we happen to use LDAP (shared by other non- > > Symfony things like our wiki and VPN). Another developer and I > > concocted a makeshift request listener to enforce authentication for > > our admin controllers. It's quite different from how SimpleCASBundle > > works (as a service) and instead functions more like Symfony 1.x's > > security.yml file. We define LDAP groups as a "request" parameter on > > the route and the listener ensures that the HTTP-authenticated user is > > a member of one of those LDAP groups. Here's an example: > > >http://gist.github.com/577549 > > > Fabien, I'm not sure how you conceive defining security requirements > > (1.x's security.yml vs. route options or something else entirely) for > > your bundle. Perhaps the CAS, HTTP Auth and OpenID handlers could all > > be annotated/tagged services (e.g. "security.handler") and the main > > request listener in SecurityBundle could request credentials from any > > available handlers or perhaps just a single one specified for the > > request - similar to how templates are rendered by specifying an > > engine (":twig" or ":php"). > > > Lukas: with respect to supporting permissions on the ORM/ODM model, I > > imagine that using something like sfDoctrineRoute in 1.x. Ideally, > > the permission check would happen before the controller, and with some > > extra route options, we could specify a model field to compare as the > > user or group/permission to be checked with SecurityBundle. A more > > complex system might be necessary to implement something like true > > ACL, though. > > > On Sep 13, 11:30 am, Lukas Kahwe Smith <[email protected]> wrote: > > > > On 13.09.2010, at 16:00, Fabien Potencier wrote: > > > > > Hi Matthias, > > > > > On 9/13/10 11:02 AM, Matthias Nothhaft wrote: > > > >> Hi, > > > > >> I've created a heavily extended version of the sfUser class in my > > > >> mdUserPlugin [1] with many additional features. (sorry, no docs, not > > > >> 100% unit tested..). I have some ideas to make it even better by > > > >> moving things into dedicated "sub services" and some other > > > >> refactorings.. For example I'm currently thinking about moving the sf > > > >> 1.4 credentials handling into its own "credential bag" so one can > > > >> easily replace it. Anyway.. I'm very interested in the sycurity > > > >> features of Symfony2. Maybe you can already give some rough > > > >> information of the new concept? > > > > > Basically, I want Symfony2 to support more than just username/password > > > > authentication methods. Symfony2 security should work easily with HTTP > > > > auth, CAS, OpenId, X509 certificates, and some more. So, the code will > > > > leave in a dedicated component (Security), and integration will be done > > > > in the FrameworkBundle bundle (should be light enough). The Security > > > > component won't be tied to any other Symfony2 components either, and > > > > will be usable outside of a Symfony2 MVC project. You can think about > > > > it as being a sfGuardPlugin on steroid. I cannot say much more than > > > > that right now as I don't have much code yet. > > > > so basically you want to improve the out of the box experience in terms > > > of authentication? of course a useful thing, but imho not sooo important. > > > i mean it didnt seem too hard to me do what something on your own in > > > symfony 1.x. at any rate its not hard to make this pluggable. > > > > where things are a lot trickier is on the permission end. i think the > > > credential support in symfony 1.x was again a nice baseline that handled > > > many many cases quite elegantly and sf*GuardPlugin nicely filled in some > > > more advanced features. > > > > but the key thing that i would like to see addressed in a more consistent > > > manner in the symfony community is checking of permissions when reading > > > models. this obviously requires support on the ORM/ODM level. > > > > regards, > > > Lukas Kahwe Smith > > > [email protected] -- 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
