On 09/21/2011 10:09 AM, Haru Mamburu wrote: Well, delete rights are not that relevant actually. By default only the document's creator can delete a document. So, unless you explicitly give delete rights to somebody, they'll only be able to delete their own documents. The delete and admin rights don't normally work on page level anyway, it's pretty hard to get hold of them if they're not explicitly granted. If you want finer grained security, you can implement them in Java, not as normal access rights, but as guard checks blocking actions according to your own custom rules. Yep, this was actually on the roadmap for 3.1, but it got postponed. Rights management is a very serious issue that needs to be tackled, but it's quite big so it will have to be approached in smaller steps. Unless you want to put very important information in non-displayed objects, the object edit mode is not that dangerous. As for rights, a user with edit rights on a page can only modify that page in non-dangerous ways: grant or deny other people edit rights. The most dangerous ones, admin and programming, can only be given at the space or wiki level, so as long as you prohibit edit rights on the space preferences page itself, nobody should be able to steal those rights. For delete, you can just implement an event listener that stops all /delete/ actions for non-admins. Well, it is safely used in many places, so everything is possible, it only depends on how deep you want to go and how much time you have to learn how to get that deep. -- Sergiu Dumitriu http://purl.org/net/sergiu/

Thanks a lot for explanation, So, as far as I understood, scenario is: - Space of the document has only view right for Group1. Our user is a member of Group1. - This user tries to edit the document in edit/inline mode by pressing the link/button generated somwhere else, not in required page. - Required page checks if our user belongs to Group1 and if true - opens document as a user with real edit rights - User in Group1 edits properties in inline mode. On pressing submit button script saves page as our edit-mode-user. - Finally Group1 user again has no edit rights and no edit menu options. In this case some behaviour is still unclear: - Logic says to me that access rights are checked before script will run. If yes, no way to run edit mode in our case. - If user presses button Save & view instead of form Submit button, what happens? Again, there is no way to script to save page with $doc.saveAsAuthor() function. Am I missing something? The second scenario loks more clear for me if scripts do ALL the job: - Required page Checks rights - Asks user via form if he wants to edit page - Sends user to ANOTHER page - This "another" page obtains all necessary data from the object properties of required page. - builds form and gives pseudo-inline mode to our user. - saves document on submit on behalf of user with edit rights. - redirects back to saved required page (by the way, redirect doesn't eat cyrillic names, and for now I don't know how to get it round) And in this case ALL pages for User from Group1 would be accessible only in XWiki's native view mode. This scenario gives a "guarantee" and deep feeling of "safe wiki" for admin , but also gives a lot of additional programming. And as far as I got - this is the only way to build ''smart -user-resistant' application. :-) But still, I'd prefer to manage all these rights via default XWiki application. Kind regards, Dmitry Bakbardin 23 сентября 2011, 11:30 от Caleb James DeLisle <calebdelisle(a)lavabit.com>om>: > Another way that you can get the results you are looking for is to write a script which does the editing > on the user's behalf. If the script document is saved by someone who has permission to edit the > document which the user wants to edit and the user needs to be able to, for example: edit only the content > of an object but not add or remove objects or change the document's main content. > The script can check that the user is permitted and provide the appropriate form then do the operation > on the user's behalf. The script can use the $doc.saveAsAuthor() function to do that. > > Caleb > > On 09/21/2011 07:31 PM, Sergiu Dumitriu wrote: > > On 09/21/2011 10:09 AM, Haru Mamburu wrote: > >> Hi! > >> > >> So, this "feature" makes absolutely useless delete rights, for example, if each and every user with edit rights can easily skip Delete and Admin Prohibition. Actually edit right behaves like admin in the allowed space. As for me it looks a little bit wierd. > > > > Well, delete rights are not that relevant actually. By default only the > > document's creator can delete a document. So, unless you explicitly give > > delete rights to somebody, they'll only be able to delete their own > > documents. > > > >> All users by default are simple, but as you mentioned, nothing stops the intruder with edit rights if he knows magic of URLs. > >> > >> For me it looks logical, that if I PROHIBITED right to delete or Admin rights - it means prohibited, but not "don't pay attention'. > > > > The delete and admin rights don't normally work on page level anyway, > > it's pretty hard to get hold of them if they're not explicitly granted. > > > > If you want finer grained security, you can implement them in Java, not > > as normal access rights, but as guard checks blocking actions according > > to your own custom rules. > > > >> For security it means VERY big black whole. And actually we don't have any instrument to track or stop it (besides watching pages). For semi-open projects, or even open, like Wikipedia it creates paradise for vandals, even if you open edit rights only for registered users. Once you can find couple of hundreds pages in Recycle bin even if nobody but Admin has ability to delete pages. :-) > >> And actually rights management contradicts wit 6 user types concept http://dev.xwiki.org/xwiki/bin/view/Design/6TypesOfXWikiUsers > >> > >> So, my proposal is: discuss and implement more precise rights management system in the neares future. Let's make XWiki more safe :-) > > > > Yep, this was actually on the roadmap for 3.1, but it got postponed. > > Rights management is a very serious issue that needs to be tackled, but > > it's quite big so it will have to be approached in smaller steps. > > > >> Thnks a lot for help, > >> > >> Dmitry > >> > >> > >> 21 сентября 2011, 17:39 от Guillaume Lerouge<guillaume(a)xwiki.com>om>: > >>> Hi Dmitry, > >>> > >>> unfortunately for your use case this is a feature of XWiki. When a user is > >>> granted edit right on a page, he is allowed to edit any object attached to > >>> that page (this is used through the "edit inline" mode as well, when editing > >>> in inline mode the user is actually updating the values of object properties > >>> in the page. > >>> > >>> One way to work around this is by making all users "simple users" by default > >>> so that the menus do not display the advanced edit options. However, users > >>> that know the right URLs will still be able to access the object edition > >>> mode. > >>> > >>> In short: sorry but no, not "safe" the way you mean it :-( > >>> > >>> Guillaume > >>> > >>> On Sat, Sep 17, 2011 at 6:57 AM, Haru Mamburu<haru_mamburu(a)mail.ru> wrote: > >>> > >>>> > >>>> Dear Users, > >>>> > >>>> XE 3.1. Playing with rights I found very unpleasant and IMO dangerous > >>>> behaviour. > >>>> > >>>> Two Default groups: XWikiAllGroup and XWikiAdminGroup > >>>> > >>>> Admin gives rigths to XWikiAllGroup to view pages - no problem. > >>>> Admin gives rigths to XWikiAllGroup to EDIT pages. From my point of view - > >>>> EDIT means only page EDIT in edit/inline mode, > >>>> but not: > >>>> - managing page access rights > >>>> - editing in editor object mode. > >>>> > >>>> I even tried to prohibit to XWikiAllGroup users Administration rights, > >>>> nothing changed. As for my project - it is a disaster. > >>>> I must separate four categories of users: > >>>> 1. All users - have View access to definite spaces. > >>>> 2. SOME registered users - have edit rights for spaces/pages (edit/inline), > >>>> create rights. BUT NO Access rights management, NO object mode editing) > > > > Unless you want to put very important information in non-displayed > > objects, the object edit mode is not that dangerous. > > > > As for rights, a user with edit rights on a page can only modify that > > page in non-dangerous ways: grant or deny other people edit rights. The > > most dangerous ones, admin and programming, can only be given at the > > space or wiki level, so as long as you prohibit edit rights on the space > > preferences page itself, nobody should be able to steal those rights. > > > > For delete, you can just implement an event listener that stops all > > /delete/ actions for non-admins. > > > >>>> 3. Admin Users with Admin rights on several spaces to delete/undelete pages > >>>> AND access rights management. > >>>> 4. XWiki Admin > >>>> > >>>> As I discovered, I can't get split second and third group. :-( > >>>> > >>>> It would be wise to avoid rights management and object editing mode > >>>> availability to "smart" users, that can bring a mess into the system in > >>>> couple of seconds. For example, "smart user" with edit rights will easily > >>>> prohibit access to pages to whole XWikiAllGroup OR he even can grant VIEW > >>>> rights ONLY to  XWikiAdminGroup with the same results - page becomes > >>>> inaccessible to non-admin users. I checked everything with a Test user in > >>>> XWikiAllGroup. > >>>> > >>>> I don't know if it is a bug or a feature, but for me it's a disaster :-( > >>>> > >>>> Is there any way to make XWiki project safe? > > > > Well, it is safely used in many places, so everything is possible, it > > only depends on how deep you want to go and how much time you have to > > learn how to get that deep. > > > >>>> Best Regards > >>>> > >>>> Dmitry Bakbardin > > > > > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users >