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 <calebdeli...@lavabit.com>: > 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<guilla...@xwiki.com>: > >>> 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_mamb...@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@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
