You're absolutely right. I didn't thought about that. But in that case, what if I need to create a GUI to allow a user to configure user's global permissions? I ended up doing something like this:
For each user you have a section where you select the type of entity for which you will configure global permissions. He selects, let's say, Article. Now I show this: Action: Create: Allow - Deny - Inherit Update: Allow - Deny - Inherit Delete: Allow - Deny - Inherit View: Allow - Deny - Inherit Change Permissions: Allow - Deny - Inherit Fields: Name: View - Edit - Inherit ..more fields These permissions are global. They apply to every instance. They're, indeed, class and class-field level permissions. Now, suppose there're no Article instances created yet. How could this user change these permissions without having any Article created and, for instance, no OID created yet? I think there's no way to create an ACL with an "empty" OID, so you'd need a class OID to configure these permissions. Thinking about your comment, maybe I could still use a class OID to configure global permissions using class ACEs, but don't use it as a parent for every Article's instances OIDs. I think class ACEs are not assigned to a specific OID, so if I check against a class level permission for an instance of an Article, it would still check for the class ACEs I assigned to the Article class OID, even if in reality this class ACE is not assigned to a specific OID, but only to a class. I could have then: - Article Class OID - Article 1 OID - Comment 1 OID - Comment 2 OID - Comment 3 OID So, assigning a class ACE to the Article Class OID for a given SID, if I later create an Article 1 and check for the same permission and for the same SID against it, it would check the class permission I assigned to the Article Class OID, because this type of ACEs are not related to a specific OID. Please correct me if I'm wrong here. I still think Class identities would be useful. First for the use case described before. This way it would be a "standard" way to create a class identity, which I think is needed. And, on the other hand, it could be useful if somehow it's possible later to implement a separate tree for CIDs (Class Identities). This would allow to represent a separate class tree representing the domain model. So having "Element Class > SubElement Class > VerySpecializedElement Class" we could configure class-level permissions to Element CID, and make its childs inherit them. This, obviusly, is just an idea. I don't know if it's worth the pain of its implementation (if it's possible) or the performance penalty of adding an additional tree. Again, thanks for reading! 2011/4/20 Johannes Schmitt <[email protected]> > The reason why class-scope permissions are not implemented using the > inheritance feature is that it would lock yourself into an inheritance tree > since there can only be one parent ACL. > > Let's say you got blog posts, and comments. > > Blog Post 1 ACL > - Comment 1 ACL > - Comment 2 ACL > - Comment 3 ACL > > Blog Post 2 ACL > - Comment 4 ACL > - Comment 5 ACL > > If you know want every author of an blog posts to be able to delete > comments for this blog post, you would set the blog post ACL as parent of > each comment ACL. This would not be possible if you would let all comments > inherit from a fake class-scope comment ACL instance because this instance > in turn could only inherit from one blog post ACL instance. > > So, the short answer is that you have more flexibility with the current > implementation. > > Regarding a class identity, I see some abuse potential there because you > only need this if the object does not exist yet (e.g. for checking a CREATE > permission). In all other cases, you should never use a class identity. > > Kind regards, > Johannes > > > On Wed, Apr 20, 2011 at 2:33 AM, Gustavo Adrian < > [email protected]> wrote: > >> 2011/4/19 Gustavo Adrian <[email protected]> >> >>> Why should we have class-scope ACE's for the OIDs of each instance of >>> Article or any other class? >> >> >> >> Indeed, I said this completely wrong. What I was trying to say is that >> it's a little bit confusing to have an ACL for an OID, which is supposed to >> be a representation of an instance of a class, and a way to insert a class >> ACE in the same ACL. I've found that having a separate OID only for the >> class is a lot easier to handle. And it allows even to represent a class >> tree using the ACL inheritance feature. There're even situations where you >> can't check for class-scope permissions without an OID representing only the >> class. Like I said in my last mail, what If I want to check if a user can >> CREATE an Article?, I need an OID to find the ACL corresponding to the SID >> of this user, and I shouldn't look for an OID of a specific Article to check >> this class permission. Maybe there isn't one because there are no articles >> created yet. As a result, I need an OID for the class. >> >> Maybe it could be useful to have a ClassIdentity or something like that? >> It could be just an ObjectIdentity but with a pre-defined identifier like >> 'class'. The thing is that, doing it like this, we wouldn't need class ACEs >> / class field ACEs anymore. These type of permissions would exists on its >> own "OID", which would be indeed a Class Identity instead of an Object >> Identity. >> >> I'm just throwing my thoughts here. It's already possible to do all the >> stuff I'm saying without any modifications. But, as I said, I'd really >> appreciate to read your opinions about this. It's healthy to talk about this >> topics :) >> >> >> Thanks in advance. >> >> -- >> 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 > -- 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
