-
Notifications
You must be signed in to change notification settings - Fork 1
RFC: ZfcAcl
RFC Author(s): Evan Coury
Several developers attempting to use ZfcAcl have voiced concerns about the design of the module, and subsequently have ended up creating more and more of their own ACL modules. Some of the concerns I've heard are:
- Does not match the patterns or practices in modules like ZfcUser.
- Does not work with ZfcUser out of the box.
- Difficult to extend and customize.
- No adherence to coding standards.
- Depends on
Zend\Aclwhich has a design that favors small containers (sub 1000 objects) - for larger ACL the performance will be unacceptable for a web app.
Please note that these are not my (Evan) words or observations. I have not had a chance to dig very deep into the ZfcAcl code committed by matuszemi yet.
I am proposing we do an audit of the current ACL modules (see below), including ZfcAcl and evaluate what we should do with ZfcAcl to help make it a more successful module (refactor, replace with another existing module, etc).
Speaking for myself (Evan), I can say that BjyAuthorize is the closest to what I had originally envisioned for an ACL module. In full disclosure, bjyounblood works for me, and thus had feedback from myself while he was creating his BjyAuthorize module.
Here's what I think we should aim for with ZfcAcl:
- Out of the box integration with ZfcUser -- There's no reason a ZfcAcl module should not "just work" with ZfcUser. However, we should design ZfcAcl such that it is still useful to those who are not using ZfcUser. This means that ZfcUser should be a soft dependency of ZfcAcl.
- Follow the existing patterns established in ZfcUser. We should strive for consistency in our practices across the ZF-Commons modules.
- Consistent with the ZF2 coding standard.
- Should be a simple wrapper around Zend\Acl -- any "guards" provided are simply for convenience, as the basic isAllowed() functionality should be able to be used in any part of the application (controllers, views, service layer, etc).
- Focus should be on making it highly extensible from third-party modules rather than supporting every type of "guard" or ACL-related feature possible. Perhaps just a base controller/action guard ships with the module, and additional guards are left up to third party module developers. We could maintain a list with links to these additional guard provider modules in the readme or wiki.
TBD.
Should we replace the current ZfcAcl implementation with BjyAuthorize?
- Rob Allen - No Vote
- Ryan Mauger - No Vote
- Ben Scholzen - No Vote
- Evan Coury - +1
- Kyle Spraggs - 0, awaiting further discussion. Artur brings up a good point but I'm curious to see understand exactly what his implementation would entail.
-
Artur Bodera - -1. If someone wants BjyAuthorize, one can easily grab it. Zfc should focus energy on drafting a better security component which would include containers (such as acl), resolvers (such as acl, rbac, hierarchical, flat, dynamic, db-based, backend-based, annotation-based etc.), adapters for everything, interfaces for easily using with (attaching to) any and all 3rd party components.
- Evan: I'm not sure how we could encompass a single module and API that encompasses acl, rbac, etc... I don't see why we couldn't go with BjyAuthorize now, as ZfcAcl is broken and abandoned, get it to 1.0, then we can look at a larger feature-set and more flexibility for a v2.0. We can always add new stuff in non-bc-breaking ways for 1.x, as well. Edit I am, indeed, interested to see what Artur's implementation would look like and entail, but I think we could look at something more in depth like that for a 2.0.
- Matthew Weier O'Phinney - No Vote
Click here to view comments and discussion for this RFC.