Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages

On 3 May 2018, at 12:27, Ecaterina Moraru (Valica) <valicac(a)gmail.com>

It would be interesting to have an Administration configuration to ask if extension customization are allowed or not: - for advanced developers that want total control of their instance and create a custom one, they would put YES and do the upgrades on their own;

- (2a) while for Cloud/MyXWiki it would be on NO, using the applications

they are and only manage the content.

On Thu, May 3, 2018 at 1:20 PM, Vincent Massol <vincent(a)massol.net>

> >> On 3 May 2018, at 12:11, Ecaterina Moraru (Valica) <valicac(a)gmail.com> > wrote: >> >> How I see this problem for extension technical pages: >> - users -> EDIT right forced false. They don't see the "Edit" button,

>> they are not tempted to edit. >> - devs -> WARN. They should be able to modify the pages, but on their

>> expense. >> - admins -> WARN. They should be able to control everything, but be

>> of the risks. > > You’re forgetting the the hosting/easy upgrade use case ;) > > Thanks > -Vincent > >> >> From what I see the above goes into 1b or 3. The only difference is if

>> should force or not the developers to be admins and also be advanced > users, >> which in practice it usually happens. >> >> Simpler visualization of the proposal, where -ED=(EDIT right to DENY)

>> W=(Warning): >> >> | Users | Admins | >> |Basic|Advanced|Basic|Advanced| >> 0 | W | W | W | W | >> 1a| -ED | W | -ED | | >> 1b| -ED | W | W | W | >> 2a| -ED | -ED | -ED | -ED | >> 2b| -ED | -ED | W | W | >> 3 | -ED | -ED | -ED | W | >> >> Thanks, >> Caty >> >> >> >> On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne < > thomas.mortagne(a)xwiki.com&gt; >> wrote: >> >>> Right I actually forgot to list one possibility in the first mail: >>> >>> 0) Warning for everyone (so what we have in 10.3) >>> >>> On Wed, May 2, 2018 at 6:56 PM, Vincent Massol &lt;vincent(a)massol.net&gt; > wrote: >>>> Hi Thomas, >>>> >>>>> On 30 Apr 2018, at 14:29, Thomas Mortagne <

>>> wrote: >>>>> >>>>> Hi xwikiers, >>>>> >>>>> In 10.3 we introduced a warning to discourage users from editing >>>>> extension pages (unless the extension indicate it's OK to edit it). >>>>> >>>>> This was a first version to have something in 10.3 but the initial >>>>> (vague) plan (for 10.4 this time) base on previous discussions was: >>>>> >>>>> * EDIT right forced false for basic users >>>>> * still a warning for advanced users >>>>> * various options to change that (EDIT right forced false for >>>>> everyone, warning for everyone, etc.) >>>> >>>> Note: I haven’t read what’s below yet (looks complex ;)). >>>> >>>> From a functional POV the minimal needs IMO are: >>>> >>>> * The warning you’ve already implemented is good as the default >>>> * We also need to take the hosting use case, where some company

>>> xwiki hosting and they want to prevent users (including admins, for >>> superadmin it’s ok) from editing extension pages so that they can > perform >>> xwiki upgrades automatically with no conflicts. >>>> >>>> Ofc if we can support Advanced user vs Simple user use cases (i.e. >>> forbid simple user from editing extension pages) that’s nice too but > less >>> important IMO. >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> That was before I actually look at what we can do with our security >>> system :) >>>>> >>>>> Turns out that it's not a huge fan of dynamic criteria like >>>>> "basic/advanced user", it's still possible but will require a big of >>>>> work. Also since ADMIN imply EDIT forbidding basic admin to edit a >>>>> protected document would not exactly be straightforward. >>>>> >>>>> Before starting big stuff I would like to discuss in more details

>>>>> we want in the end. >>>>> >>>>> In this mail I would like to focus on default behavior and we can

>>>>> about which options we need to provide in another one: >>>>> >>>>> Note: in all of theses superdamin still have the right to edit >>>>> everything (with a warning). >>>>> >>>>> 1) Basic/advanced based >>>>> >>>>> 1.a) >>>>> >>>>> Forced EDIT right to DENY for basic users. >>>>> Edit warning for advanced users. >>>>> Forced EDIT right to DENY for basic admins (we overwrite the ADMIN >>>>> implied rights logic) >>>>> >>>>> 1.b) >>>>> >>>>> Forced EDIT right to DENY for basic users. >>>>> Edit warning for advanced users. >>>>> Edit warning for admins (they get EDIT trough ADMIN right). >>>>> >>>>> 2) Admin right based >>>>> >>>>> 2.a) >>>>> >>>>> Forced EDIT right to DENY for everyone >>>>> Even admins >>>>> >>>>> 2.b) >>>>> >>>>> Forced EDIT right to DENY for everyone >>>>> Edit warning for admins (they get EDIT trough ADMIN right). >>>>> >>>>> 3) Both >>>>> >>>>> Warning if you are both advanced user and have ADMIN right >>>>> Forced EDIT right to DENY for everyone else >>>>> >>>>> WDYT ? >>>>> >>>>> The initial plan was 1.a in my mind but I'm still hesitating. 2.b is >>>>> by far the easiest to implement and probably good enough but not

>>>>> having ADMIN right is the right criteria to be allowed to force edit >>>>> of protected pages since it's not about security and more about >>>>> knowledge. >>>>> >>>>> I'm -1 for 2.a) as a default. It's way too harsh for the product

>>>>> I can understand it as an option in a cloud offering for example). >>>>> It's quite young and we will most probably forget to indicate that >>>>> some pages are OK for edit for a little while, plus there is Contrib >>>>> extensions which will probably never get configured properly because >>>>> not really maintained anymore but still used. >>>>> >>>>> In term of refactoring/hacking to the current design the most >>>>> dangerous option is working around the imply link between ADMIN and >>>>> EDIT rights. The right system was not really designed for >>>>> basic/advanced criteria use case but it's OK. >>>>> >>>>> Thanks, >>>>> -- >>>>> Thomas Mortagne >>>> >>> >>> >>> >>> -- >>> Thomas Mortagne >>> > >