[Proposal] So which protection to we want by default for extensions pages

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] So which protection to we want by default for extensions pages

Thomas Mortagne
Administrator
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.)

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
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
Hi Thomas,

> On 30 Apr 2018, at 14:29, Thomas Mortagne <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Thomas Mortagne
Administrator
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 <[hidden email]> wrote:

> Hi Thomas,
>
>> On 30 Apr 2018, at 14:29, Thomas Mortagne <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Ecaterina Moraru (Valica)
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 <[hidden email]>
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 <[hidden email]> wrote:
> > Hi Thomas,
> >
> >> On 30 Apr 2018, at 14:29, Thomas Mortagne <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator

> On 3 May 2018, at 12:11, Ecaterina Moraru (Valica) <[hidden email]> 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.

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 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 <[hidden email]>
> 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 <[hidden email]> wrote:
>>> Hi Thomas,
>>>
>>>> On 30 Apr 2018, at 14:29, Thomas Mortagne <[hidden email]>
>> 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
>>

Reply | Threaded
Open this post in threaded view
|

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

Ecaterina Moraru (Valica)
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 as
they are and only manage the content.

On Thu, May 3, 2018 at 1:20 PM, Vincent Massol <[hidden email]> wrote:

>
> > On 3 May 2018, at 12:11, Ecaterina Moraru (Valica) <[hidden email]>
> 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.
>
> 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 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 <
> [hidden email]>
> > 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 <[hidden email]>
> wrote:
> >>> Hi Thomas,
> >>>
> >>>> On 30 Apr 2018, at 14:29, Thomas Mortagne <[hidden email]>
> >> 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
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator


> On 3 May 2018, at 12:27, Ecaterina Moraru (Valica) <[hidden email]> wrote:
>
> 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;

I’m fine with simple/advanced user but Thomas mentioned that it’s hard/dangerous to do so I’m not sure we should focus on that one FTM.

> - (2a) while for Cloud/MyXWiki it would be on NO, using the applications as
> they are and only manage the content.

Note that it’s not just for Cloud/MyXWiki but any sane admin might want that on the xwiki instance he/she administers to forbid users from changing extension pages because he/she’ll be the one doing the upgrade and doesn’t any bad surprise to upgrade!

It’s actually a sane default and the more I think about it and the more I think it should be the default (and allow admins to turn page extension editing on the first time they really need it).

Thanks
-Vincent

>
> On Thu, May 3, 2018 at 1:20 PM, Vincent Massol <[hidden email]> wrote:
>
>>
>>> On 3 May 2018, at 12:11, Ecaterina Moraru (Valica) <[hidden email]>
>> 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.
>>
>> 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 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 <
>> [hidden email]>
>>> 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 <[hidden email]>
>> wrote:
>>>>> Hi Thomas,
>>>>>
>>>>>> On 30 Apr 2018, at 14:29, Thomas Mortagne <[hidden email]>
>>>> 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
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

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

Thomas Mortagne
Administrator
In reply to this post by Ecaterina Moraru (Valica)
By "users" and "devs" you mean "basic" and advanced, right ?

On Thu, May 3, 2018 at 12:11 PM, Ecaterina Moraru (Valica)
<[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> wrote:
>> > Hi Thomas,
>> >
>> >> On 30 Apr 2018, at 14:29, Thomas Mortagne <[hidden email]>
>> 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
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator


> On 3 May 2018, at 13:56, Thomas Mortagne <[hidden email]> wrote:
>
> By "users" and "devs" you mean "basic" and advanced, right ?

“simple” and “advanced” since “basic” doesn’t exist ;)

http://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/PageEditing

-Vincent

>
> On Thu, May 3, 2018 at 12:11 PM, Ecaterina Moraru (Valica)
> <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> wrote:
>>>> Hi Thomas,
>>>>
>>>>> On 30 Apr 2018, at 14:29, Thomas Mortagne <[hidden email]>
>>> 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

Reply | Threaded
Open this post in threaded view
|

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

Ecaterina Moraru (Valica)
In reply to this post by Thomas Mortagne
On Thu, May 3, 2018 at 2:56 PM, Thomas Mortagne <[hidden email]>
wrote:

> By "users" and "devs" you mean "basic" and advanced, right ?
>

It would be ideal if we could just say it's just basic or advanced. I meant
more from a purpose point of view.
"Devs" can be defined as advanced users or advanced admins, but the main
differentiator is their clear intention to modify and create apps.



>
> On Thu, May 3, 2018 at 12:11 PM, Ecaterina Moraru (Valica)
> <[hidden email]> 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 <
> [hidden email]>
> > 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 <[hidden email]>
> wrote:
> >> > Hi Thomas,
> >> >
> >> >> On 30 Apr 2018, at 14:29, Thomas Mortagne <[hidden email]
> >
> >> 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
>
Reply | Threaded
Open this post in threaded view
|

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

Thomas Mortagne
Administrator
On Thu, May 3, 2018 at 3:09 PM, Ecaterina Moraru (Valica)
<[hidden email]> wrote:

> On Thu, May 3, 2018 at 2:56 PM, Thomas Mortagne <[hidden email]>
> wrote:
>
>> By "users" and "devs" you mean "basic" and advanced, right ?
>>
>
> It would be ideal if we could just say it's just basic or advanced. I meant
> more from a purpose point of view.
> "Devs" can be defined as advanced users or advanced admins, but the main
> differentiator is their clear intention to modify and create apps.

Sure but there is no standard way to indicate that someone is a "dev"
in XWiki so I will need more details :)

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)
>> <[hidden email]> 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 <
>> [hidden email]>
>> > 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 <[hidden email]>
>> wrote:
>> >> > Hi Thomas,
>> >> >
>> >> >> On 30 Apr 2018, at 14:29, Thomas Mortagne <[hidden email]
>> >
>> >> 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
Reply | Threaded
Open this post in threaded view
|

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

Marius Dumitru Florea
In reply to this post by vmassol
On Thu, May 3, 2018 at 1:32 PM, Vincent Massol <[hidden email]> wrote:

>
>
> > On 3 May 2018, at 12:27, Ecaterina Moraru (Valica) <[hidden email]>
> wrote:
> >
> > 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;
>
> I’m fine with simple/advanced user but Thomas mentioned that it’s
> hard/dangerous to do so I’m not sure we should focus on that one FTM.
>
> > - (2a) while for Cloud/MyXWiki it would be on NO, using the applications
> as
> > they are and only manage the content.
>
>

> Note that it’s not just for Cloud/MyXWiki but any sane admin might want
> that on the xwiki instance he/she administers to forbid users from changing
> extension pages because he/she’ll be the one doing the upgrade and doesn’t
> any bad surprise to upgrade!
>

They can do this already with access rights. The problem is that:

* The Extension Manager doesn't have an UI to list the pages belonging to
an installed XAR extension
* The Admin doesn't always know which page from the extension XAR should be
protected (which is code and which is demo content)

We could probably add a step at the end of XAR extension install to allow
the administrator to configure the extension/application access rights.
This step could also be an administration section under User & Rights, e.g
"Applications" where we show a tree with installed XAR extensions at the
top and their pages below, allowing the administrator to configure the
access rights. The issue is choosing/providing a default. The default could
be based on the XAR page type, e.g. after a XAR extension is installed a
script set edit right to allow for admin group based on the page type.


>
> It’s actually a sane default and the more I think about it and the more I
> think it should be the default (and allow admins to turn page extension
> editing on the first time they really need it).
>
> Thanks
> -Vincent
>
> >
> > On Thu, May 3, 2018 at 1:20 PM, Vincent Massol <[hidden email]>
> wrote:
> >
> >>
> >>> On 3 May 2018, at 12:11, Ecaterina Moraru (Valica) <[hidden email]>
> >> 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.
> >>
> >> 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
> 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 <
> >> [hidden email]>
> >>> 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 <[hidden email]>
> >> wrote:
> >>>>> Hi Thomas,
> >>>>>
> >>>>>> On 30 Apr 2018, at 14:29, Thomas Mortagne <
> [hidden email]>
> >>>> 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
> >>>>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

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

Anca Luca
In reply to this post by Thomas Mortagne
Hello

On Thu, May 3, 2018 at 3:30 PM, Thomas Mortagne <[hidden email]>
wrote:

> On Thu, May 3, 2018 at 3:09 PM, Ecaterina Moraru (Valica)
> <[hidden email]> wrote:
> > On Thu, May 3, 2018 at 2:56 PM, Thomas Mortagne <
> [hidden email]>
> > wrote:
> >
> >> By "users" and "devs" you mean "basic" and advanced, right ?
> >>
> >
> > It would be ideal if we could just say it's just basic or advanced. I
> meant
> > more from a purpose point of view.
> > "Devs" can be defined as advanced users or advanced admins, but the main
> > differentiator is their clear intention to modify and create apps.
>
> Sure but there is no standard way to indicate that someone is a "dev"
> in XWiki so I will need more details :)
>

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)
> >> <[hidden email]> 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 <
> >> [hidden email]>
> >> > 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 <[hidden email]>
> >> wrote:
> >> >> > Hi Thomas,
> >> >> >
> >> >> >> On 30 Apr 2018, at 14:29, Thomas Mortagne <
> [hidden email]
> >> >
> >> >> 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
>
Reply | Threaded
Open this post in threaded view
|

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

Thomas Mortagne
Administrator
On Thu, May 3, 2018 at 8:14 PM, Anca Luca <[hidden email]> wrote:

> Hello
>
> On Thu, May 3, 2018 at 3:30 PM, Thomas Mortagne <[hidden email]>
> wrote:
>
>> On Thu, May 3, 2018 at 3:09 PM, Ecaterina Moraru (Valica)
>> <[hidden email]> wrote:
>> > On Thu, May 3, 2018 at 2:56 PM, Thomas Mortagne <
>> [hidden email]>
>> > wrote:
>> >
>> >> By "users" and "devs" you mean "basic" and advanced, right ?
>> >>
>> >
>> > It would be ideal if we could just say it's just basic or advanced. I
>> meant
>> > more from a purpose point of view.
>> > "Devs" can be defined as advanced users or advanced admins, but the main
>> > differentiator is their clear intention to modify and create apps.
>>
>> Sure but there is no standard way to indicate that someone is a "dev"
>> in XWiki so I will need more details :)
>>
>
> 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 long as you stick to Velocity and public APi you can still do many
things and proudly be called a dev :)

Creating an app (I guess you are refering to AWM) does not require
admin right, what require admin right is having your app show up in
the panel that's all. But I would not really include people using AWM
in a dev category you can trust with extension pages.

>
> 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)
>> >> <[hidden email]> 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 <
>> >> [hidden email]>
>> >> > 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 <[hidden email]>
>> >> wrote:
>> >> >> > Hi Thomas,
>> >> >> >
>> >> >> >> On 30 Apr 2018, at 14:29, Thomas Mortagne <
>> [hidden email]
>> >> >
>> >> >> 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
>>



--
Thomas Mortagne