Replying to both you and Kevin with this. I'm trying to find a good *generalized* mechanism, and it's not easy. I've got a couple of use cases that I've got sitting in my brain that I haven't been able to find a common answer for. Maybe the two of you can help me out with ideas.
Consider a web app like Magento: It needs to have levels of access that are not necessarily hierarchical. It can handle multiple stores, with distinct users between stores, and shared users between stores. This means that, depending on configuration options, a customer that has an account in one store automatically has an account in any other store in the same installation. It could also be the case that it has no shared customers. A person who has admin rights in one store might have no rights in another store. And then there's machine admins, and store admins. The rights can be all over the place, as you can see. Approaches: If I go with JSON-encoded permissions, then any query against a table has to somehow filter based on the current user's permissions. Considering what that list could look like, it's possible to wind up a hugely ugly query just trying to see if somebody has permission to see something. If I go with a separate table, then I can do a more straightforward join (still not necessarily easy to read, but at least more straightforward). That table can be one monster table for all tables in the system, or a separate permissions table on a per-table basis. Each of these provide their own benefits and drawbacks (especially as relates to performance), but they both will make an audit easier to perform. I suppose I could also attach a bitmask field to each row, and assign each permission a specific bit. From there, a permissions table would include users, groups, and permissions entries. Under those conditions, permissions restricting would involve simply precalculating what options would provide the necessary permissions to do something, and then do a bitmask match. With enough users, groups, etc, that could cause a performance hit, but it should be able to be limited to a specific area of the system that could then be heavily optimized. Those are the options I've got. What do you all think? On Thu, Jan 3, 2013 at 7:44 AM, Craig Small <[email protected]> wrote: > On Wed, Jan 02, 2013 at 01:41:01AM -0500, Michael Pedersen wrote: > > My question for you is this: Are you looking for view based > permissions > > (i.e.: possibly conditional portions of the page being rendered), or > are > > you looking for row based permissions (i.e.: a specific instance of > > model.Thing is only visible to a subset of users)? > > The first item is already covered very well by repoze.what > predicates. You > > can insert <py:if> statements in your code, and get the results you're > > expecting. The second case, though, I don't know of a generic way to > do > > it. > It's the second. > The admin group can see everything; that's pretty standard repoze.what > kind of task. > > Everyone else has "thier" instances of particular models. Imagine an > online store, the shopwoner can see all Orders but I can only see mine. > I can obviously do this in the controller by forcing it to filter on it > but was wondering if there was a generic way. > > > Did you get anywhere with this? If so, how did you handle these > issues? > I've not gone far with this part so no light yet. > > - Craig > -- > Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au > Debian GNU/Linux http://www.debian.org/ csmall at : debian.org > GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 > > -- > You received this message because you are subscribed to the Google Groups > "TurboGears" 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/turbogears?hl=en. > > -- Michael J. Pedersen My Online Resume: http://www.icelus.org/ -- Google+ http://plus.ly/pedersen Google Talk: [email protected] -- Twitter: pedersentg -- You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en.
