I'd like something more complex, and more flexible at the same time. Instead of having simple user names, I'd like to see a more powerful "principal" mechanism in XWiki, with roles and delegates.
A first usecase is separating users and their admin privileges. Instead of automatically granting admin privileges to users all the time, there should be a "sudo" equivalent. This gives a bit of safety against cross-XYZ / XYZ-injection attacks, since normally a user browsing the wiki wouldn't have admin/scripting/programming privileges, unless manually entering "admin mode". There wouldn't be an "Admin" user anymore, just users that can switch to "Administrator" mode, and this would be recorded as (for example): delegate::role(user::xwiki:Users.jdoe|role::administrator) delegate::role(user::xwiki:Users.jdoe|role::developer) When asking for the current principal, this is what would be returned, and stored as the author of a document after a change. We still know that it was "jdoe" performing the changes. Checking for scripting rights later is done both on the source user (if it's denied) and on the target role (if it's allowed). return <is the source denied> ? false : <is the target allowed> Another usecase would be an admin logging in as another user, to experience what the user sees without having to ask (or temporarily change) the user's password. Jira has this feature, and it's very useful for debugging rights. This can also be recorded as a delegate principal: delegate::su(user::xwiki:Users.tanderson|user::xwiki:Users.neo) A third usecase, which doesn't make much sense in the base XWiki, but which is needed in more complex applications where there's a more pronounced emphasis on groups, is when a group member acts on behalf of the group: delegate::member(user::xwiki:Users.padams|group::xwiki.Groups.Pediatricians) Here, Patch Adams is acting on behalf of the group of pediatricians when writing a press release. Another one: more info about guests. Instead of pretending that there's only one special "XWikiGuest" user, we can record more information: role::guest(ip:192.168.0.123|visit:42) Later, we can see everything this guest did. That's on the "who am I" end, but this also extends to "who should I be" part, i.e. setting rights for special roles. allow admin for role::administrator allow scripting for role::developer deny scripting for group::xwiki:Groups.TheBadGuys allow delete for role::creator deny view for role::guest allow sudo for group::xwiki:Groups.Administrators deny vote for karma::lt(100) The last one shows that the types of principals can be customized by new component implementations, and evaluating if the current principal matches a target principal can be more complex than what's there now, "is the same user" or "is member of a group". Also, the rights should be extensible, right now adding a new right is not impossible, but not very easy either. I've been working on designing and implementing this on and off for the past year, but there's still a long way to go. Just some food for thought, -0 for the proposed change. On 01/17/2017 10:54 AM, Thomas Mortagne wrote: > Hi devs, > > I'm thinking since a long time that maybe we should automatically make > superadmin the author of the pages when installing a XAR as long as > the current user (and current author) have programming right (i.e. has > the same rights than superadmin when the extension is installed). I > don't really see anything against it these days and it's easy to do so > why not. > > Basically the goal is to reduce the possibility to break extensions > when you play with existing users/groups/rights. Common user case > being to get rid of some old adminsys leaving the company. > > WDYT ? > > Note: to be complete we could imagine the same kind of thing for admin > user but that require the introduction of a virtual admin right user > like superadmin is a vitual programming right user. But let's not > discuss too many thing at once. > -- Sergiu Dumitriu http://purl.org/net/sergiu
