I'm not sure of all the implications, but if you're going to take this approach, you would have to use the "group_id" rather than the "role" when calling .has_membership() and .add_membership() (if you use the "role", it will simply identify the first group whose role matches, which may be the wrong group). Alternatively, you could subclass Auth and override __init__ (to add the organization ID as an attribute of Auth) and id_group (to use the organization ID to filter the query).
Anthony On Sunday, November 1, 2015 at 8:21:43 PM UTC-5, Alex Glaros wrote: > > would there be any security problems if I alter db.auth_group to allow > role field duplicates? > > There is a multi-tenant situation where I want users to have access to a > standard-core, common number of shared roles, but also have ability to > create their own roles. > > (1) If I use "_common_filter", users cannot access the standard-core, > shared roles, but have benefit of being able to create their own roles > without duplicating other tenants' roles. > > (2) If I do not use "_common_filter", then users can share core-standard > roles but have problem of trying to create role whose name might be > duplicate of other users' role names (not allowed in db.auth_group). > > This type of problem was solved with other files by allowing duplicate > field names but adding unique-constraint capability by adding another > field: "organization_id". > > I'd like to do that with db.auth_group but am afraid of unknown security > issues if unique role name attribute is removed. > > thanks > > Alex Glaros > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
