Hi, I think We have to decide about the level granularity which we want in the photark.What suhu is proposing makes the photark very granular and flexible but this flexibility will make the photark a bit complex.
On Sun, Jul 4, 2010 at 1:11 PM, Suhothayan Sriskandarajah < [email protected]> wrote: > On 4 July 2010 09:53, Luciano Resende <[email protected]> wrote: > > 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) > > When the Photark code is concern it don't bother in what role you are > in. It only checks the permissions and if you have the appropriate > permission you are allowed to access. > So when we take the scenario of owner adding another owner. > than having all sub set permissions > (deleteOwnAlbum,addOwnImagesToOwnAlbum, editOwnAlbumDescription + > addOrRemoveOwnerToOwnAlbums) > i can just create a permission as OwnerPermission. > > so we say the OwnerPermission have rights to add new owners, but we > have super admin it also have to have this permission, > then there will be superAdminPermission and, what if we want to have > another kind of admin! so it makes things complicated... > > so that's why in this case I create two permissions > addOrRemoveOwnerToOwnAlbums and addOrRemoveOwnerToOthersAlbums > > and when you are trying to add an owner the code will only check do > you have any of these permissions, and not who you are! > > FYI each album will have an Array of owners as attribute > > And all these different types of permissions are only used at the back > end, and they are not shown to the users directly... > When we take createGroupRole permission, if the logged in user have > that permission a "create role" button in admin panel will be shown, > else it is not shown. > > > > > >> 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. > > yes, but since we are only implementing role based access control, and > not user based access control, this is how the ui will look like > > Role Name: My Friends > Users: user1,user2,user3 > Albums: > album1 [x] ViewImages [ ] Add Images, [ ] delete images, [ ] edit > album description > album2 [x] ViewImages [x] Add Images, [ ] delete images, [x] edit > album description > album3 [x] ViewImages [ ] Add Images, [ ] delete images, [x] edit > album description > > so all the users in a particular role will have similar permissions, > and you are free to have roles with single user too, in future we can > implement user based permissions to make it even more flexible > > So the above is kind of the the ui that we get when the user is creating > roles > I think this is user friendly enough, and the user wont see the all > the different type of "owners and others" permissions, those are for > back-end, and each of then is used as a key for each method call e.g > getAlbums deleteAlbum etc so it is easy for programming, > most importantly no logic will be hard coded like owner and admin can > do A,B , but rather the permissions are hard coded > if you have permission xyz you can do A,B > > > > >> 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 > > > yes, i have not used this because new permissions may be added over time.. > like adding comments etc.. > so for now i'll store permissions as string, but later we can migrate > to numeric values > > suho > > >> 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://people.apache.org/%7Elresende> > > http://twitter.com/lresende1975 > > http://lresende.blogspot.com/ > > > -- Avdhesh Yadav http://www.avdheshyadav.com http://twitter.com/yadavavdhesh
