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

Hello On Thu, May 3, 2018 at 3:30 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: Imo, the dev persona always has admin rights. If they're described as "want to modify and create apps", both of these imply having admin rights: installing apps so that they can modify them requires admin rights, while creating a new app requires admin rights as well (I might be wrong on this one, though). Also, "developing" on a wiki often means "doing what you can from configuration and code the rest", so I guess we can safely assume that they will be admins.

As a default setting I'm actually hesitating between 2b and 0, with the possibility to restrain it further in the direction of 2a. I think it could do the job. Thanks, Anca > > IMO the closest we have right now is "advanced" so that' what I listed. > > > > > > > > >> > >> On Thu, May 3, 2018 at 12:11 PM, Ecaterina Moraru (Valica) > >> &lt;valicac(a)gmail.com&gt; wrote: > >> > How I see this problem for extension technical pages: > >> > - users -> EDIT right forced false. They don't see the "Edit" button, > so > >> > they are not tempted to edit. > >> > - devs -> WARN. They should be able to modify the pages, but on their > own > >> > expense. > >> > - admins -> WARN. They should be able to control everything, but be > aware > >> > of the risks. > >> > > >> > From what I see the above goes into 1b or 3. The only difference is > if we > >> > 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) > and > >> > 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 < > thomas.mortagne(a)xwiki.com > >> > > >> >> 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 > >> provide > >> >> 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 > >> what > >> >> >> we want in the end. > >> >> >> > >> >> >> In this mail I would like to focus on default behavior and we can > >> talk > >> >> >> 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 > sure > >> >> >> 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 > (but > >> >> >> 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 > >> >> > >> > >> > >> > >> -- > >> Thomas Mortagne > >> > > > > -- > Thomas Mortagne >