Re: [fw-mvc] RE: Acl factory the MVC way

Op Friday 21 August 2009 19:59:32 schreef Seth Atkins:
> There is really one good answer. You need a controller plugin and use
> the preDispatch method to build and check your ACL. That is if your ACL
> is going to check module/controller/action access at all. Post routing,
> the request object has filtered the RequestURI into
> module/controller/action(s) so you can construct your ACL using this
> information. And between routing and dispatch leaves pre-dispatch as
> your only option.
>
> The only choice at that point is which pre-dispatch you want to use. You
> can hitch pre-dispatch code as a method in each controller, but then you
> would have to duplicate your code a bunch of times for each controller
> which isn't very maintainable, so the best solution is to use a
> controller plugin since controller plugins are initialized prior to
> dispatching to a particular controller meaning your ACL code for
> creating and checking is in just one location.
>
> Sure you could have an ACL controller, but then that means you have to
> force all requests through that controller prior to being redispatched
> again later. Plugins are so much simpler.
>
> What I did was that I have a very simple plugin. It calls an ACL
> creation method followed by a simple isAllowed statement that checks the
> request against the ACL.
>
> Where you place the factory code and so forth is really just a matter of
> personal preference. I didn't want to bloat up my plugin, so I moved the
> heavy lifting code to another factory class. And I felt that this is a
> library, which meant I placed it in /library/MyStuff (or something like
> that). Of course with 1.8+ you have to mess with namespaces to do that,
> but not a big deal.
>
> My ACL factory in turn calls the database to gather info around
> hierarchical permissions and so forth, so that means the factory
> instantiates a Model_AAA (I felt it nice to have a simple model for all
> things authentication/authorization related), which then has a method
> for querying the database. I placed this model in the default (module)
> namespace. But put it where you want.
>
> Last comment. After lots of wrestling over how to manage hierarchical
> permissions in a database structure, I settled on a nested set structure
> rather than a recursive structure. This takes a little getting used to,
> but it handles nesting of levels of resources so much better than trying
> to recurse many times. Google around and you should find some help on
> how to manage queries against a nested set. You can do lots of things
> such as gather the full parent branch of the tree from any given
> resource, etc. as well as find every sub tree from a given node. It is
> very powerful, and you can use this for group/role nesting as well if
> you have a complex group structure.
>
>
>
>
> --Seth

Hi Seth (and all the others),
Thanks a lot for your great explanation! I appreciate it very much!

I have indeed a controller plugin exactly because of the same reason you describe (between routing and dispatch). The factory you have inside the library might be the best option. Though it contains a lot of application specific code, I see no other option. Thanks for your help.

Regarding your nested sets: I have used it for other tree like structures, but came back to the common recursive structure. The main reason was the problems updating a whole subtree having another parent (drag &drop alike). I had pretty tight db constraints which caused the lft and rgt should be unique (and so: updating the table after drag & drop is very difficult). Having the tree cached, the performance drop is really minimal related to nested sets, so I'm back to the old method now ;)

Regards, Jurian

--
Jurian Sluiman
Soflomo.com