Hi Thomas, Why not. However I haven’t thought enough about it but right now the downside I see is the loss of accountability/tracability. It’s interesting to know what user has installed a given page. Using superadmin would loose this info.

BTW and related to this, I’d prefer to have a System user instead of using superadmin. The rationale is that super admin is user and you can log with it whereas System wouldn’t be a user that you can log with. It would represent a change made by the system. This could be another discussion but I thought I would mention it here to be complete.

Thanks -Vincent

On Tue, Jan 17, 2017 at 5:08 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: On Tue, Jan 17, 2017 at 5:02 PM, Vincent Massol <vincent(a)massol.net> wrote: You can know wo installed the extension so it reduce a bit the history problem. Couldn’t we keep the author as is, and just apply this to the content author ? Wouldn’t this be sufficient for our purpose ?

The main issue is that it's not so easy to introduce new virtual users without potentially colliding with some existing user somewhere. That's the issue with possible virtual admin user too. -- Thomas Mortagne -- Denis Gervalle SOFTEC sa - CEO

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:

On Tue, Jan 17, 2017 at 5:54 PM, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; wrote: The solution you propose looks more like a hack or workaround for the the problem you mentioned. I'm +0 ATM.

Thanks, Marius > > 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. > > -- > Thomas Mortagne >