Oh, forgot this one: system::migrator(R80000XWIKI12345) system::extension-upgrade(org.xwiki.contrib:cool-app:1.2.3) system::password-reset(ip:1.2.3.4)
On 01/17/2017 02:14 PM, Sergiu Dumitriu wrote: > 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
