On Sat, Jun 27, 2015 at 10:51 AM, [email protected] <[email protected]> wrote:
> > On 27 Jun 2015 at 10:29:00, [email protected] ([email protected](mailto: > [email protected])) wrote: > > > On 26 Jun 2015 at 18:26:11, [email protected] ([email protected] > (mailto:[email protected])) wrote: > > > > > One item we haven’t discussed here again (it was discussed in some > other thread) are the Permissions. > > > > > > When we have ND, we need to decide how to set permissions for a > non-terminal page. > > > > > > Here’s what I propose: > > > > > > * Remove the current “Edit Rights” menu entry and replace that with an > “Administer page” menu entry, see > http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration . > Ask for Admin rights to be able to go to the admin UI. > > > * When on a non-terminal page (i.e. a WebHome page), go to the “Space” > Admin UI when clicking “Administer page” > > > * When on a terminal page, go to the Page Admin UI ( > http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration) > when clicking “Administer page” > Sorry, but either I do not understand or it looks too complicated for end users. > > > * Add a, xobject listener (or some other way) to prevent users without > admin rights to be able to add a Rights XObject > I am convince that we should rely on the current model, and the current abilities of the model to provide a proper security solution. If we start using tricks, it is the open door for security holes. > > > > > > Note that one use case that would be nice to support is the following: > > > * You create a page A > > > * Some other persons create pages B, C, having your page A as parent > > > * You change the permissions on page A to allow only yourself to view > it (or edit it) > > > * Suddenly people who had the rights to view or edit pages B and C > don’t have them anymore. > Not necessarily true, since we have the CREATOR right, which actually only implies DELETE at document level and undeniable, we may surely extend it to also implies VIEW and EDIT, so it given creator a more consistant right on their own page. Now if that document is non-terminal, the global rights that we set on it will still depends on WebPreferences, and actually those documents are not editable by non-admin users. > > > > > > OTOH with my proposal above you wouldn’t be anymore to have private > pages (unless you have Admin permissions). Is this acceptable? If not, do > you have a counter proposal? > This already what we have with spaces, user are not able to create private spaces unless these user are admins. This could be seen an unacceptable limitation, but counter proposal need thorough reflexion and I am not sure it is the right time of it at the moment. > > > > A counter proposal would be to introduce a Permissions to control > Permissions. This is probably what would be the more flexible and would > allow for all use cases. > > We would still need to decide if we want to use the page level permission > or the space level one when on a non-terminal page. Ideally it should be > the space level UI IMO since it has more features (hence my initial > proposal above). However, since we may want to retain the ability for a > user to edit permissions, we could allow users with > the “Permission” permission to go to that Admin page but only be able to > modify permissions while requiring Admin permissions to modify the other > options of that page. > I really do not like such change. If we would go for it, I would use separate documents to store objects that needs different levels of access. So this could means extracting global rights objects into another document than WebPreferences, and allowing EDIT rights to those that are allowed to edit permissions. Once again, I will be very careful with any proposal that do not exploit the actual model and security module to complete right purposes, since, this has been prove bad in the past. > > WDYT? > I am sorry not to have more time at the moment for a complete counter proposal, but I hope the above remarks will be helpful. Thanks, -- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
