I agree with Peter - it will also probably reduce the total number of saved permissions in the system, and this is a good thing - the fewer assigned permissions there are, the fewer there to consult each time a permission check occurs at runtime.
But to be clear - coding your application to use permission checks is almost always better than using role or group checks - if you can dynamically add or delete roles or groups at runtime, you must use permission checks. Plus because permissions describe raw functionality, they are self-documenting and only need to change when your application's functionality changes. And there is little to no interpretation as to what is required when programming to permission checks. HTH, Les On Wed, Oct 28, 2009 at 6:09 AM, Peter Ledbrook <[email protected]> wrote: >> "Project ID or Name:DomainObjectName(Building, Program) >> :Operation(edit, create, workflow, etc):DomainInstanceID" > > Sure, that works. > >> I think by adding project name / id into my wildcard, that would allow >> me to authorize somebody to have, say, read access to all buildings in >> a specific project. Any time I create a new project, I could then >> create several roles for each project so they could be assigned to >> users, i.e. ProjectX_ADMIN, ProjectX_Viewer, ProjectX_Editor, etc. >> The admin would have permissions "ProectX:*:*:*" - all permissions for >> project X. > > Consider modifying your realm so that some roles have an associated > project ID or name. The original DB realm for the Grails JSecurity > plugin was modelled in this way, with a relation table between users > and roles that contained the project ID (or anything else you wanted). > I think that would be safer in the long run than embedding the project > ID in the role name. > > Cheers, > > Peter >
