On Thu, Jan 27, 2011 at 00:52, Anca Luca <[email protected]> wrote: > I agree with this. I mean I like it as an approach that fixes an issue > in a relatively harmless way (1 + 2). >
Not sure it so harmless in term of security and it should be implemented with care. If a simple user would be capable of adding a PR requirements on one of its pages, and he could tricks the admin to fix the PR right issue, he will gains PR access. So, if the people who was not aware of PR and are admins, using the admin panel without care could let them breach the security of their site when they thinking they fix a security issue. We should be really careful on who would be able to put requirements if we really want to helps admins IMO. > > PR is really PITA, and this is known by any developer that had to send a > mail to another developer or to an administrator of their wiki with the > list of pages that should be saved with programming rights (list which > he has maintained on his desk on a pink post-it for 2 weeks or so, > adding or removing items on it whenever he did a change). Post-its are > so last century. > > I might like the idea of signed scripts but I cannot see it through > right now (don't really understand fully what it means), for various > possible reasons. Which makes me think that if I need explanation on it > now, I might need some after it's implemented and I really think we > should make the app dev environment as accessible as possible to > "normal" people. > > There are a couple of solutions for the fact that this solution is a > "patch" and not a real solution: > 1/ we don't advertise the solution as an API, we advertise it as subject > to change (because we want to build it right) so if people are not > willing to maintain it on upgrades, they should stick to the current > solution which is having no solution > I am +1 on this. If we implement such panel, we should be careful to legacy code that do not have the PR information. It is in itself an important information, and for legacy code, a possibility to fix either the PR status of a page, or the requirement of a page. I think that the panel should be able to do both ! > 2/ we implement it as an application (it doesn't need more than a .xar, > right jerome?) on extensions.xwiki.org and who needs it takes it from > there and uses it in his development environment > This is something I have never been against, but since you need to change the data you import to contains more information (an XObject with security requirements), your extension will only works when the object are add to the distribution packages and the applications and extension you install. Taking into consideration, the 2 remarks above (being able to fix either rights or requirements, and being an extension), the tools has for me a very different presentation. It could be seen has a addition to the existing tools an admin could use to manage PR. He could see it has a way to mark page he have accepted for PR and check the page keep it while also checking no other are gaining it with its knowledge. Seen that way, I should say Jerome that you had finally a great idea and I would be +1. WDYT ? > > As for objects vs doc metadata, yes, doc metadata would be nice, but > only _needed_ if we need to make a fast query (without a join to > xobjects & props tables), in my view. Which is not the case if I > understand correctly how this metadata will be used. Additionally, it > would make impossible the 2/ implementation above, it would be too "core". > > Thanks, > Anca > > On 01/19/2011 08:04 PM, Jerome Velociter wrote: > > Hi developers, > > > > I've setup and worked on a couple of wiki farms recently, and my feedback > is > > that the PR issue has become for me a major PITA. > > It's worst than before, because we've introduced a lot of pages that > > requires it : annotations style and script, plus the wiki macros for > > activity, tag cloud, space, etc. (OK, it's not really PR, it's edit right > of > > the last person who did edit it, but it's the same issue mostly : you > need > > to have it saved by someone with sufficient rights). > > > > Importing not as back-up (meaning all pages imported from the XAR are > saved > > by the user doing the import) is not sufficient answer, for several > reason : > > * User might not have programming rights > > * When user has programming rights, it's a BAD practice in terms of > security > > (it means every page of the wiki initially has the PR right OK) > > * Wiki creation is also done by template wiki copy, which is not covered > by > > this > > * This problem is not just an import/creation problem, we need generally > a > > way to know which pages require PR, and which are missing this PR (users > can > > be deleted, their rights can change, etc.). > > > > OK, that looks like sufficient complaining :) > > > > Here what I propose, tell me what you think : > > > > 1. We define a XWiki class, like XWiki.RequiredRightClass, with a field > that > > describe the required right the user saving the document must have for it > to > > behave properly (for example it will be "edit" for wiki macros with a > "wiki" > > scope, and "programming" for pages that uses privileged APIs, or JSR > > scripts, or always use SSX, etc.) > > 2. We make a simple UI (for example in the administration section of the > > admin app) that list all of them, and their current status. Plus a button > to > > fix the status if there is something to fix (a missing PR for example) > and > > if the user seeing the page has the required rights of course. > > > > That's what I propose for now. > > > > In the future, we could imagine that : > > > > 3. Programming right can only be granted on a page that requires > > it explicitly. This would be a non-backward compatible change. > > > > Let me know what you think. > > > > If we agree I volunteer to implement this in 3.0 M2. > > > > Jerome. > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
