I'm very +1 on this Jerome's proposal. We need to identify pages that require programming rights. Jerome's solution is a good one as it will allow more tight control in the future.
I believe we need an option in the programming rights checking which will allow to decide on a per wiki basis if the Object presence is checked or not to grant the rights in addition from checking the author. This will allow to progressively help fixing the issue. In the first version it's a tracking mecanism. If you activate the additional check it also enhances security.
I like it because:1/ the current mecanism cause security issue. If you are an Admin and you import a XAR you cannot be warned about which pages might contain a programming rights script that compromise your farm. With this additional mecanism you can know what you are importing (once the import tool is modified to show the pages that carry a Programming Rights object). 2/ it allows to check the status of your wiki and see if anything is wrong. I love sanity checks. I first encountered a sanity check script in bugzilla and I found that great. I've done some with CheckConfig / CheckIndexes. We need more and this is one of them.
Of course signed script are also interesting, but I think that even with them this feature is still interesting.
As for Vincent's proposal of using a Document metadata, we have SheetClass so I think we should stick to a class. It's more flexible. We might want other metadata that identify code. We also need a way to identify code in a Wiki.
We could have a class with is XWiki.CodeClass type (multiselect): groovy/sheet/jsx/csx/translations/etc.. requirerights (boolean): true/false Such a class could be used by the IDE and by Velocidoc Ludovic Le 24/01/11 09:56, Jerome Velociter a écrit :
On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle<[email protected]> wrote:On Wed, Jan 19, 2011 at 20:04, Jerome Velociter<[email protected]> 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 :)All these issues were there in 1.x ! I am now working around them since so long, that I do not understand why you are proposing a quick fix.Well, if you are working around them for so long, then I don't understand why you've not proposed a patch before ;)In a farm, issues starts with the initial template provided, which use XWiki.Admin in place of xwiki:XWiki.Admin for the contentAuthor of pages requiring PR. So, it would be a good job to first fix that one for all, since this breaks things before you even started to edit them.I don't think we want to do that. In my opinion saving ALL pages with PR right is not the proper solution. Its weak in terms of security right now, plus it only fixes import, so that's not the root of the problem.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.If you want to implement such UI, why not simply checking pages against their sources. Let say that you want to check that you have not broken the initial wiki import, you just have to provide the initial import XAR (fixed) and see which page have lost (or gained) PR since this import. This job could be even better integrated in the extension manager that could check installed extension has not been wrongly tempered since installation. This would not require any additional work on extension developer, this could even been retrofitted to the legacy application manager for older stuffs.Again if you do that you consider all pages should be saved with PR right (since there is no PR metadata in pages right now) And that's just half of the problem again: you only fix import, but you don't fix Admin user deleted, or programmer account deleted, etc.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.Even if I have been annoyed by PR issues in farm environment since long, I am almost -1 on your proposal, which seems to me increasing the complexity of the issue, in place of fixing the root cause. One more UI for admins to take care about, one more thing to explain and understands for those who have never care about it, and are probably the firsts to complains that some pages are not working properly. And on the developer side, one more stuff to take care about since there is no direct link between the requirement and a working page, so one more place for a potential bug. And obviously, once introduced, one more feature to maintain.I definitely don't agree with this. "one more thing to explain and understands " I'm very curious of how you explain the programming right to your users/admin rights now. "Well, ok, this page does not work, it misses programming rights. You don't see it, but that's how it is, you have to take my word for it. Look, now I save it with my Admin account and it just works!" Pure magic ! At least a having UI that lists such pages and show their status would help in making it understandable, and not make the situation worst as you say.We really need to fix the real cause of PR issues, and I know how hard it could be, but it is clearly what we need. IMHO, your proposal worsens the situation by amplifying the issue. Is this really the best we can do about it ?What do you propose then ? Jerome.Sorry for these late comments (and please do not feel hurt by them ;) ), I have missed the initial thread. DenisIf we agree I volunteer to implement this in 3.0 M2. Jerome. _______________________________________________ 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_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
<<attachment: ludovic.vcf>>
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
