RFC: ZfcAcl

[EvanDotPro]

Comments and discussion for: RFC: ZfcAcl.

Related zf-contributor thread on Zend\Acl.

[EvanDotPro]

Pinging ZF-Commons team for comments.

@Akrabat, @Bittarman, @DASPRiD, @SpiffyJr, @Thinkscape

[EvanDotPro]

Pinging users of the various ACL modules for comments.

@matuszemi, @adamlundrigan, @booradleys, @Ocramius, @Danielss89, @UFOMelkor, @davidwindell

[davidwindell]

I agree with the proposal to review existing modules and replace the existing ZfcAcl with either one of them or a new module that reflects the various benefits of each.

Important areas for me are;

• Simplicity in Configuration and injection of User Entity via SM
• Flexibility for handling auth failures (via events)
• No hard dependency on ZfcUser or Zend\Db
• Would like to see a Route & Controller guard at the least included.

[matuszeman]

It would be useful if each ACL module contributor could write short feature/architectural description about his module so we can understand each module better. Also we need to identity what exactly the problems are with current ZfcAcl module and how we can fix them (if feasible).

ZfcAcl

• No dependency on any of role/identity provider modules - role/identity module is responsible for implementing RoleProvider interface, which is then consumed by Acl service
• API: AclService::isAllowed($resource, $privilege)
• Provides set of Config mappers
• Usage of existing ACL implementation - Zend\Acl\Acl (treated as model in ZfcAcl). This gives us advantages of resource/role hierarchy and privilege inheritance.
• Possibility to load extra resource rules lazily - if resource does not exist AclService triggers loadResource event which can be used to load ACL for the resource.
• Guards: Dispatch, Route, Event; Guard mapper setting maps route/eventId into resourceID so that ACL rule settings are independent from guards settings and this allows us to re-use resources (what keeps ACL less complex) e.g. route for updating user should be represented by same resourceID/privilege (user/update) as service operation for it.
  • Route - maps route name to resource ID, while you can specify ACL for parent route only and all sub-routes inherits these settings.
  • Event - maps eventId into resource ID and listen to these events and throws ACL exception if unauthorized.
• (Experimental caching)

TBD

• Do we need multi-role per user?

Comments on concerns about current state of ZfcAcl

Does not match the patterns or practices in modules like ZfcUser. They have been changing since - the community expected to keep it up with latest patterns.

Does not work with ZfcUser out of the box. Does ZfcUser provide user roles? The question might also be why ZfcUser does not work out-of-the box with ZfcAcl? ZfcUser community is expected to contribute this.

Difficult to extend and customize Some examples please?

No adherence to coding standards. This can be easily fixed anytime. The module was imported into ZfcAcl namespace in highly experimental state while it was more important to agree on API itself rather than if to use space to separate opening if bracket or not.

Depends on Zend\Acl which has a design that favors small containers (sub 1000 objects) - for larger ACL the performance will be unacceptable for a web app. I see no reason why this module should not depend on Zend\Acl model/component - it provides what we need - if we feel the component itself needs refactoring we should do so.

[EvanDotPro]

@matuszemi Why would ZfcUser provide roles but not ACL? That makes no sense, as a role is worthless without any notion of ACL. I strongly believe that it should be up to the ACL module to provide all notion of roles.

[Thinkscape]

Depends on Zend\Acl which has a design that favors small containers (sub 1000 objects) - for larger ACL the performance will be unacceptable for a web app.

For those not aware of the issue: Zend\Acl is based on the principle of loading and instantiating every single role, resource and rule in memory. This is required to resolve even the simplest of rules with this component. Because of some quirks it's hard to serialize and deserialize the whole container and even with that trick, it still takes a lot of time to do so and a lot of memory to hold all data. Assuming that an average (successful) web application will grow to hundreds of thousands roles and potentially tens of thousands resources, it will take several seconds and hundreds of MB of memory just to init Zend\Acl.

Assuming it's used for things like allowing people to log in or perform some tasks on data entities, Acl checks are performed very often, which leads to a very serious performance problem for the application.

The solution is SQL db backed ACL, which relies on db queries for checking permissions. It's very easy to implement and is trivial to scale. Consider your roles, resources and rules as properly indexed and denormalized db tables. ACL check against that is just a single compound query, while complex ACL checks can be handled with stored routines.

Second option is using document databases, like Mongo or Reddis. All of them support map-reduce which is perfect for scalable ACL resolvers, which can run against (distributed) collections of hundreds of thousands records to resolve even the most complex ACL queries in under a second.

Both of these solutions of course require minimal memory footprint and no cpu cycles on the php app server.

[matuszeman]

@EvanDotPro OK agree - but at the same time you need ZfcUser to work out what current user/role is. I was thinking more about ZfcUserAcl module which implements the role provider and some role management for ZfcUser users.

@Thinkscape Hmmm... but let's consider another end now - you have small web-app (no DB) and you define simple ACL configured from config file - in this case using Zend\Acl\Acl would benefit us. What about Zend\Acl\AclInterface - with at least one method isAllowed($role = null, $resource = null, $privilege = null)? This will be swappable (at a level of AclService) so developer can choose what "Acl resolver" suits more their needs.

[EvanDotPro]

OK agree - but at the same time you need ZfcUser to work out what current user/role is. I was thinking more about ZfcUserAcl module which implements the role provider and some role management for ZfcUser users.

The only reason @bjyoungblood started on ZfcUserAcl was due to the design of ZfcAcl. It does not make any logical sense for ZfcUser to have a notion of roles, but ZfcAcl did not provide this either, thus we needed this "glue" module to sit in between the two. This was one of the reasons @bjyoungblood decided to go ahead and make BjyAuthorize. The idea was to provide a seamless experience, as it ships with a "ZfcUser" identity provider by default that just works, though any other user-type module can provide their own.

I honestly do not think we should have ZfcUser + ZfcAcl, and then a third module, ZfcUserAcl that glues to the two together. That could possibly be justified if they were two separate modules from different vendors, but there's no reason we can't make the Zfc* modules work nicely with each other by default. Keep in mind, I'm not talking about ZfcAcl having a hard dependency on ZfcUser. If we go with the design in BjyAuthorize, you can swap out the identity provider, so the ZfcUser provider would simply be a default / soft dependency.

[Thinkscape]

I agree with what @EvanDotPro just proposed - one of the goals of Zfc is to have any (decent) level of integration, which might be an inspiration for other module developers. If even Zfc modules cannot talk to each other (and need bridges/adapters), then the whole modular approach goes down in flames.

On the other hand, a propoer separation of concerns is always desired. Now we'll just have to figure out the proper balance of having separation with integration that allows out of the box inter-operation of those two components.

As for the resolver, @matuszemi, in order for the db resolver to work it has to be fed with data. This means that the constant in-memory adding/removing of definitions inside Acl has to stop, at service level or otherwise.

Notice that ZfcUser entities are also stored in a database, but their "phantoms", in-memory acl roles are about to be thrown all into a config file? That doesn't make much sense to me.

[ghost]

What about SpiffySecurity / Rbac ?

[matuszeman]

@EvanDotPro what in case we start to implementing UI for ACL management and user-role assignment? Where would these classes go?

@Thinkscape "a propoer separation of concerns is always desired" - yep yep ... we just need to discuss to find a balance.

Notice that ZfcUser entities are also stored in a database, but their "phantoms", in-memory acl roles are about to be thrown all into a config file? That doesn't make much sense to me.

When implementing some module in ZF2 I always try to think from most simple possible use-cases to "high-end" implementation with DB/webservice mappers. So having users in DB and ACL definition in config (or any other source) is acceptable (desired) for me. That's why ACL config file definition would make sense to me in some cases - and it does work for me now. Also it's not only users in "user" table you might want to authenticate. It's just flexibility is what I'm after.

[EvanDotPro]

@booradleys said: What about SpiffySecurity / Rbac ?

I really don't have anything against RBAC (in fact, I was hoping @Freeaqingme's RBAC RFC for ZF1 would go somewhere). Currently @SpiffyJr has his own RBAC implementation in SpiffySecurity. I believe he has plans to make a formal RFC for an RBAC component to be included in ZF2 eventually (2.x?), and if this is the case, I'd be 100% in favor of refactoring is module into a ZfcRbac module or something. Maybe if there's enough interest and the ZF-Commons team is open for maintaining it, we could adopt it before the component is accepted into ZF proper (thus the module would be serving as an incubator of sorts). It could be good to give users a choice between ACL and RBAC, granted we have clear documentation explaining the differences, advantages, disadvantages, etc. Of course this would be up to the community and a vote of the ZF-Commons team. These opinions are merely my own. :)

[Thinkscape]

So having users in DB and ACL definition in config (or any other source) is acceptable (desired) for me.

Could you describe what you're exactly doing there? So do you have a db table for users, but also a value in array in a php config file somewhere for each and every of those users? Or do you use some group definitions? how does that work?

[matuszeman]

@Thinkscape When you authenticate (using credentials stored in DB) you get 'user' role. ACL roles/resources/rules are defined in config file.

[EvanDotPro]

@Thinkscape said: On the other hand, a propoer separation of concerns is always desired. Now we'll just have to figure out the proper balance of having separation with integration that allows out of the box inter-operation of those two components.

At the risk of sounding partial / biased, I do believe BjyAuthorize is a perfect example of this balance. (Disclosure: @bjyoungblood works for me.)

@matuszemi said: So having users in DB and ACL definition in config (or any other source) is acceptable (desired) for me. That's why ACL config file definition would make sense to me in some cases - and it does work for me now.

Honestly, I've always pictured config-file ACL rules more as a unit testing tool, however, I can see where there may be some use for small, simple applications where you simply need just a few rules set up very quickly. However, in this case, I'd still probably have, at minimum, a user-to-role table in the DB. Having just a single authenticated role, 'user' and 'guest' for unauthenticated users would not really provide the advantage of an ACL. At that point, you might as well just check if the user is logged in everywhere rather than performing ACL assertions.

[matuszeman]

@EvanDotPro we don't have any DB ACL mapper yet and we've been using ACL since and from config file - isn't this an advantage that "yes, we can" ;) "at minimum, a user-to-role table in the DB"/"just check if the user is logged in everywhere rather than performing ACL assertions" -- but then once everything is implemented and you need to implement proper ACL you'll need to go back and rewrite the code. I'd rather rely on consistent ACL API as you application permission requirements might change in the future. Also I never needed to implement ACL checks in the code itself (so far) -- I was able to achieve this using Event/Route guards. So basically I write an services/controllers and then once tested I set ACL for everything as required from config file and everything becomes "protected".

[davidwindell]

@matuszemi I don't see any reason to rewrite code, memory based config should be easy to swap against database config through standardised interfaces.

[matuszeman]

@davidwindell I was talking about ACL API vs $authService->hasIdentity() -- "At that point, you might as well just check if the user is logged in everywhere rather than performing ACL assertion"

[EvanDotPro]

@matuszemi wrote:

@EvanDotPro wrote: at minimum, a user-to-role table in the DB .... just check if the user is logged in everywhere rather than performing ACL assertions

but then once everything is implemented and you need to implement proper ACL you'll need to go back and rewrite the code. I'd rather rely on consistent ACL API as you application permission requirements might change in the future.

Of course. You obviously wouldn't really do that in practice. I was simply making a point that your use-case was overly simple compared with what will be encountered in the real world.

[Thinkscape]

@Thinkscape When you authenticate (using credentials stored in DB) you get 'user' role. ACL roles/resources/rules are defined in config file.

@matuszemi Well, that's oversimplification of things. Does that mean all your users are equal? You probably have a column for group name or role name or at least isAdmin INT(1) to hold that information.

Same applies to resources. ACL is useless if you use roles named user and resources all named resource. You'd be better of just checking $user->id or $user->isAdmin === true or whatever. And if they are not equal, then you have an application that somebody besides you uses. That means near-Cartesian product of at least couple hundred users, times any number of resources you might define (or your users create), times any number of rules you define. This will be noticeable even in a small application. I've done my homework when evaluating zf1 Zend_Acl and I've profiled it in detail. It just takes too much time just to construct the ACL container, even if the query itself is only 1ms.

Scanning through other responses - yes, we could make the ACL storage and resolving adapter-based. That would allow us to provide different types of resolvers working off different data sets (in-memory, db-based, file-based, query against JobServer etc.).

[Thinkscape]

btw: the only thing I found as a downside to db-based resolution was not being able to use lambda-based rules (i.e. fetching something from ServiceManager, checking against a class and giving out a verdict).

But... if we kept a common interface, then we could have both! One could have 2 resolvers - the primary being db-based, and secondary could be EventListener-based, or just foreach and invoke a few custom permission checking methods. This allows for scalability (with db) and flexibility (because we can still use custom functions for special cases).

[pensiero]

I agree with EvanDotPro, BjyAuthorize is better and more intelligible for me that i'm not a big developer and i have approached to ZfcUser, so I think it's better to develop one thing instead of two and develop it better.

[juriansluiman]

To what extend is Zend\Acl the biggest bottleneck? If so, why not address that issue first and then get into a ZfcAcl? If Zend\Acl isn't a component with zf2 performance like the other new components, it is imho better to get the base right first. And there is a chance now to remove Zend\Acl from the 2.0 release and work on it for 2.1.

[Thinkscape]

I agree with @juriansluiman.

Some people really want to depend on (keep compatibility with) Zend\Acl, but it's an old dog.

Current Zend\Acl is a port from ZF1 Zend_Acl. We should remove it, reimagine it, create an RFC and then re-introduce in a new form. I strongly believe we should make it modular - everything should be pluggable/replaceable with user components, or with 3rd party modules. It should allow for multiple adapters, multiple ways of retrieving, matching, querying and storing data - all interchangeable, conforming to common interfaces.

[Danielss89]

Agree with the 2 prev posts. I think a ZfcAcl should use Zend\Acl, though not the current one. So +1 for reinventing Zend\Acl first.

[bjyoungblood]

As @juriansluiman said, we need to figure out to what extend Zend\Acl before we decide to completely redo it. I think it's fine the way it is -- as an ACL container. It should not necessarily be responsible for loading its own data because that functionality is so dependent on userland code.

That means near-Cartesian product of at least couple hundred users, times any number of resources you might define (or your users create), times any number of rules you define.

This is totally unnecessary and is the exact reason Zend\Acl\Assertion\Assertion exists. Any time a user with role X tries to access resource type Y, the Assertion is called with the user's role, the resource name, and the privilege being accessed. The only problem with this method is trying to figure out which instance of the resource is being queried within the assertion, which can probably be solved with a minor refactoring.

If you'd like an example of how I have worked around this in the past (under ZF1), check out the following links. It's obviously not the most elegant solution, but it works. It doesn't require a total rewrite of Zend\Acl, nor does it require a rewrite in order to be improved.

https://github.com/mtd/issues/blob/master/application/modules/default/services/Acl.php https://github.com/mtd/issues/blob/master/library/Issues/Model/Abstract.php#L32 https://github.com/mtd/issues/blob/master/application/modules/default/models/Acl/HasPermissionAssertion.php

[Thinkscape]

@bjyoungblood I know this solution, I've been doing that 5 years ago and it sucks. I ended removing Zend_Acl completely.

Zend\Acl\Assertion is a "last resort" type of thing. If I need a custom function to inject models every time for each query, then why would I need the whole Acl component? Why not just

Service\Permissions::hasAccess(UserModel $user, $what)

.... a custom service that does the same thing, but does not require instantiation and will do basically what the HasPermissionAssertion above does + one more if for the actual check.

Of course this totally ignores user groups, permissions, multiple resources etc. Again - if primitive Zend\Acl container is injected with real-time data each time there's an assertion, then why do I need the Acl? why all this overhead? If it's all JIT injection, then the container would (at any given time) only contain 1 role, 1 resource and a few rules ?

I won't even go into permission queries - for example: show me all users that have write access to resources belonging to group resource_group_a. With current implementation, impossible unless you instantiate each and every model from db, then go with each and every resource, all rules and assertions, and loop through the whole thing. Good luck :)

You've just confirmed what I said earlier, by stating it's a workaround. My proposal is to forget workarounds and build a proper 2012 php acl solution, make it scallable to make both small developers happy, and put MS ActiveDirectory ACL to shame ;) We can also easily make the new component BC with old one, give it the same in-memory containers (adapters), rules, resources and roles.

[yanickrochon]

I am also in favor of removing Zend\Acl and refactor it, especially if it's merely a port from ZF1.x. I always ended up not using Zend_Acl before and I figure it will most likely be the same with ZF2. That component does not meet ZF2 coding standard and performance.

I believe an adapter approach to Zend\Acl will benefit both small and large role management needs; where one might be content with Zend\Acl\PhpArray while another would prefer Zend\Acl\Db (even Zend\Acl\Mongo?), for example.

Also, rules should be alias-based, where each alias could be mapped to routes and/or controller/actions (built-in into ZfcAcl), or just about any other resource that third party modules could check against using the SM.

Just like User configs, Acl rules and config should be located in a local config file (in the application's config/autoload folder). By defaults, the ZfcAcl config files should not require any modifications.

[bjyoungblood]

@Thinkscape I think if you want to be able to run permission queries the way you explained, a dynamic ACL is probably not the optimal solution to your problem -- you might be happer with RBAC. You're absolutely right you'd have to instantiate the whole ACL which is a giant mess, but the strength of ACL is that you don't have to do that in order to run an isAllowed query.

@yanickrochon First, why did you end up not using Zend_Acl? Secondly, I don't think an adapter approach is necessarily good behavior in this case. If someone ends up trying to use an RDBMS as a storage backend, you need to be a bit more careful about loading. A naive solution might load roles and rules lazily and indiscriminately, potentially resulting in an astronomical number of queries. Why can't Zend\Acl just be a container (especially when there are so many different strategies for loading data into an ACL)?

I'm not really sure what use-case you have in mind when you mention alias-based rules. I don't really see how aliasing rules would offer a significant advantage as a part of Zend\Acl.

It's definitely possible to load ACL data from config files using the service manager.

---

Correct me if I'm wrong, but it seems that a lot of people want the functionality (especially ACL loading) provided by the various ACL-helper modules to be a part of Zend\Acl. I just don't think that's the right way to go, and here's why:

As it stands, Zend\Acl is merely a container with some logic attached. What's wrong with keeping it that way? It's flexible and it has a singular purpose. Any extra stuff should be provided via modules, whether they're official or third-party. If you ask me, this is exactly the situation modules were made for, especially considering the wide variety of strategies that could be used to set up and manage an ACL.

tl;dr: instead of scrapping a critical component with a fairly sensible public API, let's try to figure out how to improve its performance (e.g. it should use SPL objects internally) and let's make sure we find a way to address all the outstanding bugs (e.g. the allow/deny mix bug).

[yanickrochon]

@bjyoungblood it's been about three to four years now since last time I had to play with Zend_Acl, but we followed the docs and tried to setup a moderate ACL for a project that involved mixed roles and rules for users and what I do remember is that there was always one test case failing for some reason (not to mention the odd way roles and rules had to be declared). When we thought it worked, there was always at least one use case where it failed and we ended up writing a view helper to handle our in-house ACL (which worked and passed all use cases, much faster than Zend_Acl did anyway).

If rules and roles are stored in a hierarchical way, querying a DB is not complicated and will not only save on memory footprint, but also on CPU power. But I'm not saying such DB adapter should be part of Zend\Acl. Such adapters could be part of an external module (ie. ZfcAcl) and would implement an interface (ie. Zend\Acl\RulesProviderInterface) that would declare a method (ie. hasAccess($role, $what)) called by some validation/guard process. Although, Zend\Acl would implement that interface for (ex.) Zend\Acl\PhpArrayRulesProvider where the application would feed it a PHP array.

Something like that.

[Thinkscape]

As it stands, Zend\Acl is merely a container with some logic attached. What's wrong with keeping it that way? It's flexible and it has a singular purpose.

... to be slow ? :-) Yes, it's a container and it does not work properly with mid and large apps, because it is not scallable. What I'm proposing is creating a proper access control component, not container. This component would include a container and a resolver, but the resolver does not need the whole container to be filled in with data.

You cannot fix Zend\Acl with modules. You'll only make it slower and introduce more overhead. Most modules listed by @EvanDotPro use Zend\Acl and add-on more features like those guards or firewalls or whatever. The problem is, it's getting slower and slower with each action, resources, role, rule, each new assertion.... and in case of MVC, this overhead is now per-request which can be deadly.

[ghost]

The RecursiveIterator strategy I used in SpiffySecurity (https://github.com/SpiffyJr/SpiffySecurity/tree/master/src/SpiffySecurity/Rbac) could be used in Zend\Acl. It removes a lot of code from the old Registry style.

[ghost]

What about this stuff ;-)

[bjyoungblood]

It's been some time since this discussion cooled off, so I'll try to get something going again.

Regardless of our decision to replace it, ZfcAcl needs to be officially deprecated. It has not been updated in three months, and as such is in a state of de facto deprecation. There are better, simpler, and maintained modules out there.

Can we get a vote on removing ZfcAcl from ZF-Commons?

[srayner]

Can you point me to alternative modules?

On Mon, Aug 27, 2012 at 4:53 PM, Ben Youngblood notifications@github.comwrote:

It's been some time since this discussion cooled off, so I'll try to get something going again.

Regardless of our decision to replace it, ZfcAcl needs to be officially deprecated. It has not been updated in three months, and as such is in a state of de facto deprecation. There are better, simpler, and _maintained_modules out there.

Can we get a vote on removing ZfcAcl from ZF-Commons?

— Reply to this email directly or view it on GitHubhttps://github.com/ZF-Commons/RFC/issues/1#issuecomment-8060293.

[juriansluiman]

@bjyoungblood I agree the current ZfcAcl needs to be deprecated. It's the first small step getting us somewhere.

@srayner this issue is related to an RFC in the ZF-Commons repository. You can find alternatives to the current ZfcAcl there: https://github.com/ZF-Commons/RFC/wiki/RFC:-ZfcAcl

[matuszeman]

Hi there! after a long holiday break I'm back "in action". This is what I propose (and I'm going to work on today):

• fix current ZfcAcl to a working state
• update README.md on the top with "deprecated" message: "ZfcAcl module (as it is now) is deprecated. Please read https://github.com/ZF-Commons/RFC/wiki/RFC:-ZfcAcl for further info."
• trigger E_USER_DEPRECATED message in the code.
• [see what happens]

Matus

[matuszeman]

I just realized there is no point of fixing what nobody is using nor being developer friendly by triggering deprecated message. Thus this sounds like a better plan:

• remove all repo files.
• replace README.md with message: "ZfcAcl module is deprecated. For alternative solutions and further info read https://github.com/ZF-Commons/RFC/wiki/RFC:-ZfcAcl"

[matuszeman]

Also it would be interesting to know what "ACL" modules others use... could you let us/me know?

[srayner]

i'm using bjyAuthorize. I have controller guards working. I don't understand how Rule Providers are supposed to work. Are these used in conjunction with or instead of controller guards.

My requirements for an ACL module would be;

• integration with zfcUser
• user-role mappings
• roles that can inherit from other roles
• resources that inherit from other resources (eg, index inherits from read; create, update and delete inherit from write)
• resources map to controller actions
• dynamic access rules stored in a database (mySQL via doctrine)
• method to obtain list of all resources a role is allowed to access
• method to obtain list of roles that can access a resource

not sure how much of this belongs in an ACL module

[srayner]

Also there should be no need to load entire rule base into Zend/ACL. Only rules relating to requested controller action should be required. If rules are stored in a database i assume there would need to be one extra SQL query for each HTTP request. Would this be a big performance hit?

[juriansluiman]

I agree with @srayner here: all the points from his list are wishes from me too. The last two are perhaps not in the direct scope of ZfcAcl, but are useful for management of roles and resources if you put the permission list in the database (think of ZfcAdmin, ZfcUser, ZfcUserAdmin).

One thing I'd like to mention is not everybody use controller/action as resources for their ACL, but routes should possibly be "protected" too. However, for myself using controller/action pairs is enough: In ensemble it would be a nightmare to preprocess the routes to protect them with ACL and it's much simpler to directly assert controllers/actions here.

About database queries: it must be possible to cache the ACL somewhere. I did this on a global app state before, making ACL terribly slow (eventually all resources and all roles are cached in one object) but perhaps a cache per session (so assertion only has to happen once) would be nice. If your "anonymous" role is cached by default and user-based ACL is cached when they log in, it is overseeable (is that a word?) in terms of maintenance ánd performance.

Ping @EvanDotPro and @bjyoungblood: how matches the expectations of @srayner (and me) in the current implementation of BjyAuthorize?

[bjyoungblood]

@matuszemi I'm not aware of many other modules that provide this functionality. Of list @EvanDotPro provided in the RFC, two have not been updated some time so I don't know whether they are actively maintained or whether they work with the current ZF2 RC, and @SpiffyJr decided to go with RBAC instead.

@juriansluiman BjyAuthorize currently supports all but the last two items the list @srayner provided. Those seem easily accomplished in userland (by getting the ACL from BjyAuthorize and looping through all the resources, querying whether a role can access them).

Because Zend\Acl is designed to work without loading everything into the ACL, I don't feel this functionality belongs in an ACL module, as it'd be up to the user to ensure all ACL components have been loaded in order for the module to return correct/complete data.

Because I just have the notion of role/resource/rule providers in BjyAuthorize, you can get the ACL data from wherever you want and support caching without touching the module's core. It'd also be possible to use Zend\Cache to proxy BjyAuthorize.

[srayner]

Another thought.

If a request is unauthorized I like to use the following strategy;

If the user is not logged in (ie guest/default), redirect to login view, then after successful login redirect to original request

If the user is logged in (ie not guest/default), show unauthorized view.

Do others agree this is resonable strategy? If so, then login view is in zfcUser module and unauthorized view is in auth module (e.g. BjyAuthorize). How would this work? Would this introduce a tight coupling or dependency between modules. Could it be configurable so as not to force a dependency?

[davidwindell]

@srayner The best way to do this would be to create an Event Listener that is attached to the unauthorized event. That's what we do with SpiffySecurity and it works well.

[EvanDotPro]

I'm going to propose we have a vote to replace the current ZfcAcl code with BjyAuthorize (refactoring the namespace). We can work out the further details later, but we shouldn't keep ZfcAcl in it's current unmaintained state.

[Danielss89]

+1

On Mon, Sep 10, 2012 at 11:22 AM, Evan Coury notifications@github.comwrote:

I'm going to propose we have a vote to replace the current ZfcAcl code with BjyAuthorize (refactoring the namespace). We can work out the further details later, but we shouldn't keep ZfcAcl in it's current unmaintained state.

— Reply to this email directly or view it on GitHubhttps://github.com/ZF-Commons/RFC/issues/1#issuecomment-8418161.

[yanickrochon]

+1

[matuszeman]

+1 -- I will need some generally accepted ACL solution very soon... when do u think BjyAuthorize->ZfcAcl can be done?

[bjyoungblood]

@matuszemi I just pushed a branch of BjyAuthorize with the rename: https://github.com/bjyoungblood/BjyAuthorize/tree/zfcacl