Zend Framework: Zend_Acl dynamic loading Component Proposal
| Proposed Component Name | Zend_Acl dynamic loading |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Acl dynamic loading |
| Proposers | Aldemar Bernal |
| Zend Liaison | Ralph Schindler |
| Revision | 1.0 - 17 November 2007: Proporsal created. 1.1 - 21 January 2008: UCs Created. (wiki revision: 35) |
Table of Contents
1. Overview
Zend_Acl dynamic loading isn't meant to be a replacement of the current good implementation of Zend_Acl, it is just an update proporsal based on get better performance in the component in medium/large ACL implementations as well as a base to allow the load of persistenced ACLs (from a database or a file or ..).
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
- This update will boost performance in medium/large Acl Implementations.
- This update will allow the component to load only the needed Roles/Resources.
- This update will allow the component to load data from datasources.
4. Dependencies on Other Framework Components
- Zend_Acl
- Zend_Acl_Role
- Zend_Acl_Resource
- Zend_Acl_Exception
5. Theory of Operation
This update doesn't make any change of current Zend_Acl implementations, it includes only a new method called registerLoader in the Zend_Acl component and a new abstract class called Zend_Acl_Loader_Abstract. The main goal of this new feature is to be able to load dynamically Roles and Resources using an instance of the abstract class. Here an example is given to make clearer the new functionality and its use:
My/AclLoader.php:
At bootstrap:
So, as you could see in the example above, the Loader class will allow to avoid the problem of loading all ACL at once in bootstrap, and will help to only load the data needed, the results are better response times and less memory usage.
6. Milestones / Tasks
- Milestone 1: [DONE] Create ZF Wiki info.
- Milestone 2: [DONE] Working prototype and some examples. UCs implemented click here to download.
- Milestone 3: Working prototype checked into the incubator supporting use cases.
- Milestone 4: Unit tests exist, work, and are checked into SVN.
- Milestone 5: Initial documentation exists.
7. Class Index
- Zend_Acl
- Zend_Acl_Loader_Abstract
8. Use Cases
I recommend you to download this file where you can find all UCs implemented for better comprehension of the component use.
9. Class Skeletons
Thanks Nuno for your comments,
well, Zend_Auth would only require one table, an ACL storage would require one or multiple tables, that depends on how is your ACL structure. Maybe if there is some kind of standard way of doing it, we could implement it. But, you could also use UC-4 in order to work with a database.
Aldemar
I think Michael Ziegler MyACL class is a good starting point. UC-4 does allow database usage but without any king of storage you will be calling the database every time you load a new page and/or check for a new permission. Lots of users, lots of resources and a database intensive site, it's likely to stall the server with the current Zend_ACL (database) usage.
Nuno - once you register this loader into your Acl object, you must store this object (Acl object that also contains the loader) into session, so you are not registering and doing queries every time a page is loaded, that's only done when it is needed (when something is not found in the session Acl object).
Aldemar
Nuno - I don't really understand why the current implementation would discourage 'big sites'. Can you provide a little more information around the way your ACL is structured so that it opens up some reasons why ZF's ACL is/isn't suitable?
I've found some issues with Zend_Acl that have been resolved with a little ingenuity from the community (dynamic resources for one!) We may need to 'fatten' up with Zend_Acl section with some further documentation to show how ACLs can be expanded upon - integration with Zend_Auth, MVC and database backends are subjects that crop up quite a bit.
Aldemar, had you considered opening up the scope of 'registerLoader' so that you could selectively apply modules to different parts of the site? E.g. registerLoader(new myAclLoaderOrders(), 'orders') could be mapped to an orders module, whilst another registerLoader(new myAclLoaderReports(), 'reports') applies to a completely separate MVC module. It then opens up the possibilities of selective loading based on module name, so in effect you could register 5+ modules, some of which may apply to 1 or more modules.
Please see the explanation i gave to Aldemar. You mention yourself that it was ingenuity (custom implementations) that allowed Zend_ACL to be usable with the expectations of the "real world" (database, MVC and Zend_Auth). Let's see if i can explain what i had in mind...
I had my ACL like this: Module/Page based on user level.
A table would then contain
Module - Page - Level
According to the user access level a tree would be built and stored in a SESSION. This would be the user actual ACL and could be used to dynamically build the app menu. Something like:
SESSION
-[0]
--[module_name]
--[module_link]
---[0]
----[module_page_name]
----[module_page_link]
---[1]
----[module_page_name]
----[module_page_link]
-[1]
--[module_name]
--[module_link]
(etc)
It didn't matter how many tables i was using or the level of fine tuning involved (i had groups, overrides and even another unrelated acl check). One database call, one session with the entire acl for that user then I would auto-check in bootstrap and no more worries about it.
In theory, i could use the MyACL class with dynamic loading and just store the object myself. But IMHO the current object is still a little bloated and contains insecure information (like database access). So, that was more or less the (high) expectation i was looking for.
Anyway, further documentation on the MVC and database integration is still welcome.
| Zend Official Comment This proposal is accepted to the Labratory. Currently, this proposal does not fully demonstrate the problem that is being solved by this proposed component. We suggest that this proposal is developed in the labratory so that both the problem and solution can become clearer, and that this proposal might become more detailed. |
I thought a little bit about how something like this could be implemented using structures similar to those already used by other components and for me the way Zend_Cache uses backends (Zend_Cache_Backend_*) to save data fit best.
The existing Zend_Acl methods could be modified and the class itself could be extended by some methods to implement this.
Hmmm Felix, I don't get your point. Is this an idea about storing the Zend_Acl object? if it is, then this proposal is about something else, it's about dynamic loading roles/resources/permissions. If I'm wrong about it please make me know.
Aldemar
Basically I combined your idea of dynamically loading ACL data with complete storage of ACL data. I thought of defining an interface for backends which could be used to save and load ACL data from other sources (e.g. databases: Zend_Acl_Backend_Database
) and presented just another way of implementing such a behaviour with structures similar to those already used by other components.
ZF Home Page
Code Browser
Wiki Dashboard
Hello Aldemar,
First and foremost, a big thanks for your work in this proposal. Most people wont realize this but ACL/MVC integration and dynamic loading is keeping the Zend Framework away (w/o custom implementations) from big sites.
Before "converting" into the Zend Framework I developed an ACL method for loading the entire user permission system on login, and then use it for AC and menu building (with TREE assistance).
So, my question is, have you contemplated any kind of storage (like Zend_Auth) for your proposals?
The idea in my mind for a complete ACL system is:
1. User logs in.
2. User entire MVC ACL is fetched (from db) and loaded using your loader.
3. Object is stored in SESSION and freely used through out the application.
4. Changes to the user ACL could be made on the fly as needed using your loader.
The advantages are obvious: only one database call, possibility for automatic MVC ACL checks and stored acl ready to be used for other options like menu building or backoffice changes.