On Sat, Jul 3, 2010 at 11:41 AM, Suhothayan Sriskandarajah <[email protected]> wrote: > On 3 July 2010 23:04, Luciano Resende <[email protected]> wrote: >> I was looking into the proposed Repository Structure [1] for Roles, >> Permissions and other user related stuff, and I have couple questions >> : >> >> - I noticed we defined couple permissions such as : deleteOwnAlbum, >> deleteOwnGroupRole, manageOwnGroupRole, addOwnImagesToOwnAlbum, >> editOwnAlbumDescription. What I found a little awkward is that, if I'm >> the owner of the album, is there really any scenario where I wouldn't >> be allowed to "manage" my album ? >> >> - As for couple other roles : deleteOtherAlbum, deleteOthersGroupRole, >> viewImagesOnOthersAlbum, addOwnImagesToOthersAlbum, >> deleteImagesFromOthersAlbum, editOthersAlbumDescription. This also >> seems strange, as it seems that once i get "deleteOtherAlbum" I would >> have permission to delete any album that I don't own, which I think >> the scenario should be more like, a specific album owner would give a >> specific user the permission to "remove album" which would only work >> on the scope to that specific album. >> >> Thoughts ? >> > > we can divide the Albums in to three major categories > 1. your (owners) album - and what you can do in your album > 2. others album - what permissions do you have on others album - in general > 3. specific albums - and the special permissions to it > > So when it comes to your albums there is no need and no way to > differentiate each of them > and you will have same permissions. Some of those permissions are > deleteOwnAlbum, > addOwnImagesToOwnAlbum, editOwnAlbumDescription similarly for your > groups (deleteOwnGroupRole, manageOwnGroupRole) >
IMO, a Owner role would suffice here and would make things simpler. > I'm using different types of permissions for two reasons > 1. Imagine a user have crated an album but due to his misconduct super > admin decided not to allow him to add any further images, in this case > the SuperAdmin can create a role with only viewImagesOnOwnAlbum > permission and add him. I think you have probably identified two new requirements : 1) the user has uploaded a inappropriate image, the admin is not happy with that and "block a specific image" 2) the user has uploaded inappropriate contents for several times, admin goes and block user account and all his contents are not visible anymore to the website. If we have this two, we can probably handle all your "misbehaved owner" scenarios. Another possible think to have in mind is that a Owner could add another Owner to a album (e.g for group type of work) > 2. managing roles and managing albums can be separated > 3. no need to hard code > Sure, how can I add a new role, or a new type of permission (e.g. allowSomeoneToDoSomethingElse) without adding new code ? > here I have divided the permissions as much as I can, so when creating > the roles there wont be any restrictions. > If we have a subset of the permissions you are proposing : viewImages, addImages, deleteImages, editAlbumDescription, and we manage a matrix of say, for each album, the Admin or Owner can add a user and select the values for each of these permissions for the album Album: Boston Add User : lresende [x] ViewImages [ ] Add Images, [ ] delete images, [ ] edit album description.... If we have this level of granularity, we are already being much, much more flexible then a lot of well known galleries which basically allows you to make albums public, private, or shared with a sub set of users. > The "others album" concept is mainly used to reduce "per album" > entries, this will facilitate roles like SuperAdmin and Moderator(can > viewImagesOnOthersAlbum and deleteImagesFromOthersAlbum) > If you treat this cases based on ROLES, this should simplify as well (e.g. when ask the access control if user can do something, if role = ADMIN, true, if role = OWNER, true, else if user has permission to do X in Album Y, return true.... and then you only need to check individual user permission for a given resource if they are not on particular ROLES.) > and thirdly the per album based permissions are used ( viewImages, > addImages,deleteImages, editAlbumDescription) > > when calculating the permissions for a user, first the general > permissions (own and others) and then the specific album based > permissions will be applied. By this approach mainly the roles like > SuperAdmin and Moderator will only have very few entries than having > 100 entries for all 100 albums in the repository, and by having all > permissions at primitive level the flexibility to create different > type of roles also increases . > If you store roles as a numeric value, you might get a more compact persisted representation. http://www.zzee.com/solutions/linux-permissions.shtml#numeric > Suho > >> [1] >> https://cwiki.apache.org/confluence/display/PHOTARKxWIKI/Repository+Structure >> >> -- Having said all of this, my main goal here is to flush out some of the ideas behind the structure, try to see if there areas we can simplify, basically to try to help you reduce the scope and be able to focus on what is the most important scenarios for PhotArk today. And if we have time, spend some time cleaning up and componentizing the good security related services we are producing. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
