I'm just thinking out loud, so I didn't think about this taking into account all the possible edge cases, but maybe creating a new entity (in this example would be useful with an ORM) which stores the following information:
AllowedPermission: - Class - ObjectID - SecurityIdentityID - Permission (VIEW, CREATE, etc.) - Fields (if this is a VIEW or UPDATE permission, it could be useful to store in the same object the list of fields separated with pipes which are allowed of the operation. So if you're using this to paginate, you have this field to know which fields you can show to the user) This class would represent only object level allowed permissions. We're not interested in class level permissions, as they can be checked in the traditional way. Then, at the moment you're modifying an ACL, you could update this table reflecting the changes you've made. For example, suppose you're modifying the ACL related to an object. Right after the modification, you ask to the ACL to know which permissions are granted for the object and security identity in question. After that, with this information, update AllowedPermission accordingly. Then, when you need to create a paginated list of objects, you simply join AllowedPermission using the relevant information. Another thing would be to take into account changes in ACLs that have children. These ACLs should be checked too and then update AllowedPermissions accordingly. As I said, I didn't think all the edge cases and I didn't use this solution yet so I don't know 100% if this could work, and depending on how you're using the ACL component in your app you'd have to tune this to suit your needs. For example, if you need to paginate over a list of Documents in MongoDB, AllowedPermission maybe could be an embedded object instead in each of your domain objects. "class" and "objectId" fields wouldn't be useful anymore. Of course, and depending on your use case, maybe using this could mean LOTS of objects embedded in each domain object, but I don't know if there's another way. The main benefit of this is that the ACLs could stay in its own DB, you wouldn't have to touch SQL directly, and it could work with other data mappers, like an ODM. An important point to remember: If the security identity you're modifying is the parent of others security identities (maybe it's a group), or if other security identities depends on it, then you should do this check for them too. The same applies for objects. If you DENY a permission to VIEW an Article for User A, then User A shouldn't be able to VIEW its comments. So all entries of AllowedPermission referred to these comments, this user and the VIEW permission should be removed too. Is this a viable solution? 2011/11/4 Lukas Kahwe Smith <[email protected]> > > On Nov 3, 2011, at 19:45 , Joshua wrote: > > > Hi All, > > > > So for about 6 months I've been looking into how to use ACL for > > fetching multiple entities in a pager format (meaning a fixeed number > > of items). I've been unable to find a solution - there is a dozen > > unanswered posts about this on StackOverflow so I think it's a real > > concern - I have seen some heavy heavy patch on github to attempt this > > but that was it. > > > > I think this is a very common issue - the only answer offered are > > always - fetch all items and then do your acl which is ridiculous and > > completely unviable solution for a site that has more than a handful > > of entities. The other suggestion is to perform sql joins with the > > acl tables myself - which them makes me wonder as to the design of the > > acl component. > > > > I would really really like some core devs to address this - if it is > > possible then please please add this to the documentation. We've been > > wanting to switch from 1.2 to 2 but cannot use ACL until this is > > addressed. > > > I do not think its really possible or at least it will require a major > effort. > Essentially it would require storing the ACL's in the same database system > as the content you want to fetch and then manipulating the query before its > executed to add whatever is needed to perform the ACL checks inside the > query. This would be a major departure from the current approach, which is > much simpler, but also way more flexible. > > I see 3 possible solutions: > 1) Implement something like I explained above independently. Back when I > was working on PEAR::LiveUser I did exactly that, although since I wasnt > using an ORM I manually added the relevant checks to my queries. With > Doctrine it should be possible to add an SQLWalker to automate that. > 2) When querying the database, do not set a limit and do not use buffered > results and then simply iterate over the result until you have exactly the > number of results you need and then free the result set > 3) If you are mostly in need of this for content management apps, help the > CMF [1] team to implement the planned support for ACL checks inside PHPCR > [2] > > regards, > Lukas Kahwe Smith > [email protected] > > [1] http://cmf.symfony.com > [2] http://phpcr.github.com > > -- > 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 > -- 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
