No graph database needed the way we implemented it. We use a regular db and generate the graph in-memory.
The current simple implementation is to query auth_permissions where table_name = 'auth_group' so we only get entries that are relevant to group-group ownerships. The graph is kept in memory and updated periodically. This avoid recursive queries into the database as all entries are retrieved in one call. This structure is shared between *all* users, so not pulled at every login. We refresh the structure periodically (every 60 seconds in our case). Disadvantage is what happens if there are so many group-group permissions that they don't fit in memory. Also, a periodic refresh is not as accurate as an event based refresh (only refresh when a group-group entry is created/modified/deleted in permissions) I see your point about the alternate architecture - one that implements a layer on top of RBAC and creates the appropriate auth_permission entries for each group/sub-group. In this situation, if you create a building under a sub-group, you would create two entries in auth_permission, one for the sub-group and one for the top-level group. This is good when you want to just retrieve all buildings that a user has access to, not as useful when you want to create a hierarchical view for the user (for example, a drill-down list of sub-groups kinda like windows shows files and folders - you see a list of all files in the top level folder, and a list of subfolders that you can click to view files within that subfolder). Using a layer on top of the RBAC would mean we have to do recursive queries anyway to show the top-level view (i.e. show me all buildings that are owned by the top-level group AND not owned by any of the sub-groups). Not sure if I'm explaining it clearly. It seems like a generic use-case so I was hoping there was a standard design pattern we could follow. Maybe by having a different permission name when the group owns a building directly, vs when a group has access to a building through a sub-group? I'm happy to work on the n+1 query problem on RBAC, is there a reference thread somewhere that I can use as a jumping off point? On Wednesday, September 30, 2015 at 3:46:12 PM UTC-4, Niphlod wrote: > > This has been discussed before and trashed as soon as a graph database is > needed to store and retrieve efficiently data. > Of course, recursive queries are a no-go. > There's a reason why Active Directory through Kerberos sends out the > flattened list of group membership when trying to authenticate. > And a reason why even with that trick it's fading away. We don't need to > copy behaviour from a well known architecture which has already proven its > limits. > Checking membership recursively at login-time is FAR FAR FAR worse than > just managing group membership on another layer, on top of RBAC which isn't > limiting from the "turing" perspective. > > PS: web2py suffers of the n+1 query problem EVEN for not nested groups. I > assume it was done to support noSQL database. I realized it reviewing the > code in order to allow JWT authentication. IMHO the eventual "refactoring > hours" spent on RBAC should be spent there instead of nested groups > functionality > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
