CanList...() static authorization method?

SonOfPirate posted on Thursday, December 21, 2006

Has anyone implemented and/or does it make any sense to have a CanList...() static authorization method, such as CanListProjects()?

This would be synonymous to an NTFS "List Folder" permission in that it would grant users the right to view a list of objects (Projects) whereas CanRead...() grants the user permission to view the item's properties/details.

In the ProjectTracker sample there is no authorization check made in the ProjectList.GetProjectList() method to inhibit unauthorized users from viewing a list of projects.  Wouldn't it make sense to at a minimum check to see that the user can read project before dumping the data?  And, I can see the possibility where you would want to allow a user read-only access to the list but not grant them access to the full details of an individual item, thus the notion of an addition CanListProjects() static authorization method on the class.

The method would return true if the right was explicitly granted or implicitly (if CanRead...(), CanEdit...() or CanDelete...()).  Something like:

public static bool CanListProjects()
{
    if (Csla.ApplicationContext.User.IsInRole("ProjectManager"))
        return true;
 
    return (CanReadProjects() || CanEditProjects() || CanDeleteProjects());
}

Any thoughts?

 

ajj3085 replied on Thursday, December 21, 2006

I usually have a CanLoad for collections, although I've never thought about granting implicit rights based on whether or not the user can edit or delete.   Sounds like a workable solution, as long as those other rights should always implicity grant a 'list' right.

SonOfPirate replied on Thursday, December 21, 2006

Yea, I'm trying to remember the relationships - it's been a while since I've dealt with it.  But, obviously you are implicitly granted read access if you are explicitly given edit rights.  If you can read projects, then you should be able to look at them in list form - thus the implicit authorization there.  And, how else could you delete an item if you couldn't see it in a list to select?  So, that's where that one comes from.  It's the add/create one that gets me.  I'm assuming that it is possible to allow a user to create a new item but not view it in a list or make changes to it after it has been saved (edit); although I can't think of a time when this was actually the case...

I know you can see this in action by setting the security on a file in Windows.  If you click "Read & Execute", "Read" is automatically checked since it is implicitly granted by the selection.  I'm thinking along those same lines so if I had a UI wired-up to these methods, you'd see the same effect as the rules changes.

I was just surprised to see that there was no provision for this in the book and/or sample app, so I figured I'd toss it up for discussion to see if I was in left-field or not.  Sounds like I'm not alone if I am .