[xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
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.
Hi Jérôme, On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome@xwiki.com> 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 :)
Though I'll abstain myself just this one time, I could add a lot of complaining here as well :-)
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.
+1, sounds good to me for a first version.
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.
Great, thanks for tackling this issue! Guillaume
Jerome. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi Jerome, On Jan 19, 2011, at 8: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.
Most (if not all of these) should be fixed too to not require PR IMO.
(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.)
So an error will happen at save time if the user saving doesn't have the right? So this mechanism is only used when saving documents. At execution time it'll remain the same mechanism and checks as now right? Also how does this solve the issue you mentioned with importing a XAR? If the user importing it doesn't have PR the page will fail to be saved. So you'll either need to scan the XAR to warn about pages that will have problems if the user doesn't have PR or you need a UI to list pages in error after the import in order to fix them. Best IMO is to refuse to import pages that have PR if you don't have PR (ie if you import 10 pages with one requiring PR then you refuse to perform the import altogether as otherwise you're left with an inconsistent set of pages). What about backup packs for which the page is saved with its original user? How is that different from now?
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.
Would we allow anyone with simple edit rights from removing the RequiredRightClass object? AFAIU this object is just indicative and not required for security. It's just used as a "helper" when saving/importing documents, correct? Regarding macros we also discussed in the past about adding a parameter to mention which right is required for a macro to execute. For example: {{velocity ... requiredRight="programming"}} ... {{/velocity}} I also know that Caleb mentioned using signatures in macros on IRC (I don't think he sent a proposal for that on the list though).
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.
Not sure I understand this point.
Let me know what you think.
If we agree I volunteer to implement this in 3.0 M2.
There's also the possibility of adding document metadata inside the XWikiDocument object (as a private field) itself and not through an XObject. Since this looks like some core metadata it could be a solution too. It would require a DB schema change (one more column) and a specialized UI in edit mode though... Let's see what others think. Generally speaking our PR mechanism looks a bit like a kludge. Thanks -Vincent
Jerome.
On Thu, Jan 20, 2011 at 1:10 PM, Vincent Massol <vincent@massol.net> wrote:
Hi Jerome,
On Jan 19, 2011, at 8: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.
Most (if not all of these) should be fixed too to not require PR IMO.
(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.)
So an error will happen at save time if the user saving doesn't have the right?
No, actually this is not even in my proposal. Though I agree it's a good idea, but for me it's a nice to have, and can be done later in my opinion. Right now my proposal is about : * providing an UI that lists pages "in error" (= that are not saved with sufficient rights), and a way to fix them easily. (It would also list PR pages not in error of course) * giving a way for extension developers to declare which pages requires such rights, so they get listed in the UI above
So this mechanism is only used when saving documents. At execution time it'll remain the same mechanism and checks as now right?
Also how does this solve the issue you mentioned with importing a XAR? If the user importing it doesn't have PR the page will fail to be saved. So you'll either need to scan the XAR to warn about pages that will have problems if the user doesn't have PR or you need a UI to list pages in error after the import in order to fix them. Best IMO is to refuse to import pages that have PR if you don't have PR (ie if you import 10 pages with one requiring PR then you refuse to perform the import altogether as otherwise you're left with an inconsistent set of pages).
Again, I don't want to change import or save behavior yet. That would be in a second step, for me.
What about backup packs for which the page is saved with its original user? How is that different from now?
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.
Would we allow anyone with simple edit rights from removing the RequiredRightClass object? AFAIU this object is just indicative and not required for security. It's just used as a "helper" when saving/importing documents, correct?
Regarding macros we also discussed in the past about adding a parameter to mention which right is required for a macro to execute. For example: {{velocity ... requiredRight="programming"}} ... {{/velocity}}
I also know that Caleb mentioned using signatures in macros on IRC (I don't think he sent a proposal for that on the list though).
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.
Not sure I understand this point.
Let me know what you think.
If we agree I volunteer to implement this in 3.0 M2.
There's also the possibility of adding document metadata inside the XWikiDocument object (as a private field) itself and not through an XObject. Since this looks like some core metadata it could be a solution too. It would require a DB schema change (one more column) and a specialized UI in edit mode though...
It's a good idea. However, I tend to think separating content and objects (having PR right flag on macros and on individual objects) does not bring too much value, since at the end of the day the page is only saved by one author. So as soon as something, a macro, an object, requires programming right, it's like the whole page needs it. In the future it could be different, if we introduce the notion of signed script or signed objects, but let's face it, we are not there yet (and it requires a lot of UI work before it can be used). What I'd like we do right now is have solution not too intrusive (like the DB schema changes would be) and not too complex so that we can kill the pain, until we work on a more profound redesign of the programmer rights. Jerome.
Let's see what others think.
Generally speaking our PR mechanism looks a bit like a kludge.
Thanks -Vincent
Jerome.
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
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.
+1 as a quick fix.
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.
In the future this will be done with signed scripts. The work is halfway done, with the xwiki-crypto module in place. That way you'd be sure only trusted scripts are executable.
Let me know what you think.
If we agree I volunteer to implement this in 3.0 M2.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome@xwiki.com> 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. 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.
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.
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. 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 ? Sorry for these late comments (and please do not feel hurt by them ;) ), I have missed the initial thread. Denis
If we agree I volunteer to implement this in 3.0 M2.
Jerome. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle <dgl@softec.lu> wrote:
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome@xwiki.com> 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.
Denis
If we agree I volunteer to implement this in 3.0 M2.
Jerome. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Jan 24, 2011 at 09:56, Jerome Velociter <jerome@xwiki.com> wrote:
On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle <dgl@softec.lu> wrote:
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome@xwiki.com> 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 ;)
Precisely because it is not an easy fix, and that I am not in favor of increasing the complexity of this situation with an quick fix. ;)
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.
This is only about contentAuthor (not author) of pages that require PR rights. I have never said that we should do so for ALL pages, just that the one that require PR should have a proper contentAuthor that works for wikis in a farm like it works for standalone wikis.
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)
No, you can know from an import the pages that have initially receive PR. These pages are those containing a contentAuthor having PR right on the current wiki. If XAR are properly built, as I suggest above and probably many farm admin had patch them, either in XAR or in their templates, checking against such XAR should reveal which page had initially require PR.
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.
Deleting Admin user is a very bad idea currently, since initial XAR use them. Currently, I advice farms admins to use this single xwiki:XWikiAdmin user to provide programming rights, unless they really have an issue sharing access to this account. There have been discussion on this list, by Vincent if I well remember, of using a 'system' user to avoid the issue of changing or deleting the Admin account. This would be not so hard to introduce, and I am sure this would help a lot providing correct XARs.
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.
Well, I could not disagree, but why should you explain PR in first place ? This should works without having someone that check it. Until you need to extend it yourself, you should be able to use XWiki without knowing that PR exists. Once you add a new admin panel, you will have to explain it that is all I said.
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 ?
1) I propose that initial and application XARs are properly built to put PR where it is needed, even in a farm (using a 'system' user or xwiki:XWiki.Admin at least) 2) Reduce the number of pages requiring PR, by providing non-PR interface to function that currently require them (isn't it a goal in progress?) 3) Change the way to provide PR to a script (ie: signing them) Denis
Jerome.
Sorry for these late comments (and please do not feel hurt by them ;) ),
I
have missed the initial thread.
Denis
If we agree I volunteer to implement this in 3.0 M2.
Jerome. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mon, Jan 24, 2011 at 11:23 AM, Denis Gervalle <dgl@softec.lu> wrote:
On Mon, Jan 24, 2011 at 09:56, Jerome Velociter <jerome@xwiki.com> wrote:
On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle <dgl@softec.lu> wrote:
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome@xwiki.com> 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 ;)
Precisely because it is not an easy fix, and that I am not in favor of increasing the complexity of this situation with an quick fix. ;)
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.
This is only about contentAuthor (not author) of pages that require PR rights. I have never said that we should do so for ALL pages, just that the one that require PR should have a proper contentAuthor that works for wikis in a farm like it works for standalone wikis.
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)
No, you can know from an import the pages that have initially receive PR. These pages are those containing a contentAuthor having PR right on the current wiki. If XAR are properly built, as I suggest above and probably many farm admin had patch them, either in XAR or in their templates, checking against such XAR should reveal which page had initially require PR.
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.
Deleting Admin user is a very bad idea currently, since initial XAR use them. Currently, I advice farms admins to use this single xwiki:XWikiAdmin user to provide programming rights, unless they really have an issue sharing access to this account.
There have been discussion on this list, by Vincent if I well remember, of using a 'system' user to avoid the issue of changing or deleting the Admin account. This would be not so hard to introduce, and I am sure this would help a lot providing correct XARs.
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.
Well, I could not disagree, but why should you explain PR in first place ? This should works without having someone that check it. Until you need to extend it yourself, you should be able to use XWiki without knowing that PR exists. Once you add a new admin panel, you will have to explain it that is all I said.
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 ?
1) I propose that initial and application XARs are properly built to put PR where it is needed, even in a farm (using a 'system' user or xwiki:XWiki.Admin at least) 2) Reduce the number of pages requiring PR, by providing non-PR interface to function that currently require them (isn't it a goal in progress?) 3) Change the way to provide PR to a script (ie: signing them)
1) does not fix the problem. It only fixes your use case. It does not handle : * Local admins or editors saving pages that require PR right thus breaking features (without even knowing it !) * Programmers account deletion, or loss of PR 2) I guess we all agree with that 3) We are not there yet, as I said. Personally I will not have time any time soon to get my hands on this, and this item has not been planned on the roadmap. If you or someone else volunteer to tackle it in releases not too far that would be just great. In the meantime I don't agree with the vision where we hide our PR problem under the carpet, and refuse to explain it because we have found a way to "almost live with it". Again, for me just fixing the import of XARs with PR pages is not satisfactory. We need to be able to detect quickly when a feature/app/script is broken because it misses it's programming right, for whatever reason it misses it. I hope you can reconsider your "almost veto". Jerome.
Denis
Jerome.
Sorry for these late comments (and please do not feel hurt by them ;) ),
I
have missed the initial thread.
Denis
If we agree I volunteer to implement this in 3.0 M2.
Jerome. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Jan 24, 2011 at 16:08, Jerome Velociter <jerome@xwiki.com> wrote:
On Mon, Jan 24, 2011 at 11:23 AM, Denis Gervalle <dgl@softec.lu> wrote:
On Mon, Jan 24, 2011 at 09:56, Jerome Velociter <jerome@xwiki.com> wrote:
On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle <dgl@softec.lu> wrote:
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome@xwiki.com> 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 ;)
Precisely because it is not an easy fix, and that I am not in favor of increasing the complexity of this situation with an quick fix. ;)
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.
This is only about contentAuthor (not author) of pages that require PR rights. I have never said that we should do so for ALL pages, just that the one that require PR should have a proper contentAuthor that works for wikis in a farm like it works for standalone wikis.
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)
No, you can know from an import the pages that have initially receive PR. These pages are those containing a contentAuthor having PR right on the current wiki. If XAR are properly built, as I suggest above and probably many farm admin had patch them, either in XAR or in their templates, checking against such XAR should reveal which page had initially require PR.
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.
Deleting Admin user is a very bad idea currently, since initial XAR use them. Currently, I advice farms admins to use this single xwiki:XWikiAdmin user to provide programming rights, unless they really have an issue sharing access to this account.
There have been discussion on this list, by Vincent if I well remember, of using a 'system' user to avoid the issue of changing or deleting the Admin account. This would be not so hard to introduce, and I am sure this would help a lot providing correct XARs.
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.
Well, I could not disagree, but why should you explain PR in first place ? This should works without having someone that check it. Until you need to extend it yourself, you should be able to use XWiki without knowing that PR exists. Once you add a new admin panel, you will have to explain it that is all I said.
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 ?
1) I propose that initial and application XARs are properly built to put PR where it is needed, even in a farm (using a 'system' user or xwiki:XWiki.Admin at least) 2) Reduce the number of pages requiring PR, by providing non-PR interface to function that currently require them (isn't it a goal in progress?) 3) Change the way to provide PR to a script (ie: signing them)
1) does not fix the problem. It only fixes your use case.
Well, but this is the use case that cause most trouble in a farm currently.
It does not handle : * Local admins or editors saving pages that require PR right thus breaking features (without even knowing it !) * Programmers account deletion, or loss of PR
Those who have edit rights on these pages and use it, should already know that they expose them to breakage, and these guys should not be many on a given XWiki. This makes me think that we should also improve initial access rights on the pages (I does that since so long that I have forgotten it)
2) I guess we all agree with that
nice :)
3) We are not there yet, as I said. Personally I will not have time any time soon to get my hands on this, and this item has not been planned on the roadmap. If you or someone else volunteer to tackle it in releases not too far that would be just great.
I do not see good reason to suddenly want to tackle this issue with a quick fix, while it was there since two major release already. I completely understand your point here, since it expose the reasons why nothing have been done. I would be more than happy if someone volunteer, I know Caled has done a good job already looking at these issue, but AFAIK, he have concluded that we should wait more before moving this forward. In the meantime I don't agree with the vision where we hide our PR
problem under the carpet, and refuse to explain it because we have found a way to "almost live with it".
If PR are working out of the box, most user will never have to look at it, but these users will surely found an additional complexity in your panel. You may say that this point is minor. From my clients, major criticisms I receive regarding XWiki is about its overall complexity for doing sometime simple things. And most of them are in regards to access rights. We have had long discussion with Cathy regarding a new interface for them, part of which would better show PR on document. I would really prefer to see these put in place but I know that it will require more time than your proposal.
Again, for me just fixing the import of XARs with PR pages is not satisfactory.
But we live with not fixed ones since so long, that it should be our first steps before anything else IMHO.
We need to be able to detect quickly when a feature/app/script is broken because it misses it's programming right, for whatever reason it misses it.
If you really want that, this could be a extension that you may build on comparing XAR with living applications. I agree that this could be a little bit more trickier, but it have the double advantage of not adding new meta-information and not being a core panel that impact all applications. This addition of new informations without any guarantee that these informations are reflecting the true reality of access rights, is for me going in the wrong direction and increasing complexity of the issue. Once your panel is in place, and it based its conclusion on possibly missing informations (old page imported in a previous version), user will complains even more. Using the contentAuthor field of initial XAR used for import to provide the same panel is probably more reliable and backward compatible. This leads to some questions: 1) What would be the interface of your panel ? (important to be careful on clarity) 2) What would you present for pages that have PR and no meta information saying it require it ? 3) What would you present for pages that haven't PR but meta information requiring it ?
I hope you can reconsider your "almost veto".
So to resume what I dislike: 1) it adds a new admin panel that increase the overall complexity of XWiki, could not it be optional ? 2) it require additional informations to deduce the needs of PR, which may be absent in migrating XWikis, and could result in the reverse of what we are trying to fix; but increasing the complexity of the issue. I will not veto if no one else does but I would be happy the ear comments from others on my comments. Denis
Jerome.
Denis
Jerome.
Sorry for these late comments (and please do not feel hurt by them ;)
),
I
have missed the initial thread.
Denis
If we agree I volunteer to implement this in 3.0 M2.
Jerome. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mon, Jan 24, 2011 at 5:32 PM, Denis Gervalle <dgl@softec.lu> wrote:
On Mon, Jan 24, 2011 at 16:08, Jerome Velociter <jerome@xwiki.com> wrote:
On Mon, Jan 24, 2011 at 11:23 AM, Denis Gervalle <dgl@softec.lu> wrote:
On Mon, Jan 24, 2011 at 09:56, Jerome Velociter <jerome@xwiki.com> wrote:
On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle <dgl@softec.lu> wrote:
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome@xwiki.com> 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 ;)
Precisely because it is not an easy fix, and that I am not in favor of increasing the complexity of this situation with an quick fix. ;)
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.
This is only about contentAuthor (not author) of pages that require PR rights. I have never said that we should do so for ALL pages, just that the one that require PR should have a proper contentAuthor that works for wikis in a farm like it works for standalone wikis.
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)
No, you can know from an import the pages that have initially receive PR. These pages are those containing a contentAuthor having PR right on the current wiki. If XAR are properly built, as I suggest above and probably many farm admin had patch them, either in XAR or in their templates, checking against such XAR should reveal which page had initially require PR.
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.
Deleting Admin user is a very bad idea currently, since initial XAR use them. Currently, I advice farms admins to use this single xwiki:XWikiAdmin user to provide programming rights, unless they really have an issue sharing access to this account.
There have been discussion on this list, by Vincent if I well remember, of using a 'system' user to avoid the issue of changing or deleting the Admin account. This would be not so hard to introduce, and I am sure this would help a lot providing correct XARs.
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.
Well, I could not disagree, but why should you explain PR in first place ? This should works without having someone that check it. Until you need to extend it yourself, you should be able to use XWiki without knowing that PR exists. Once you add a new admin panel, you will have to explain it that is all I said.
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 ?
1) I propose that initial and application XARs are properly built to put PR where it is needed, even in a farm (using a 'system' user or xwiki:XWiki.Admin at least) 2) Reduce the number of pages requiring PR, by providing non-PR interface to function that currently require them (isn't it a goal in progress?) 3) Change the way to provide PR to a script (ie: signing them)
1) does not fix the problem. It only fixes your use case.
Well, but this is the use case that cause most trouble in a farm currently.
It does not handle : * Local admins or editors saving pages that require PR right thus breaking features (without even knowing it !) * Programmers account deletion, or loss of PR
Those who have edit rights on these pages and use it, should already know that they expose them to breakage, and these guys should not be many on a given XWiki. This makes me think that we should also improve initial access rights on the pages (I does that since so long that I have forgotten it)
That's a good idea.
2) I guess we all agree with that
nice :)
3) We are not there yet, as I said. Personally I will not have time any time soon to get my hands on this, and this item has not been planned on the roadmap. If you or someone else volunteer to tackle it in releases not too far that would be just great.
I do not see good reason to suddenly want to tackle this issue with a quick fix, while it was there since two major release already. I completely understand your point here, since it expose the reasons why nothing have been done. I would be more than happy if someone volunteer, I know Caled has done a good job already looking at these issue, but AFAIK, he have concluded that we should wait more before moving this forward.
In the meantime I don't agree with the vision where we hide our PR
problem under the carpet, and refuse to explain it because we have found a way to "almost live with it".
If PR are working out of the box, most user will never have to look at it, but these users will surely found an additional complexity in your panel. You may say that this point is minor. From my clients, major criticisms I receive regarding XWiki is about its overall complexity for doing sometime simple things. And most of them are in regards to access rights. We have had long discussion with Cathy regarding a new interface for them, part of which would better show PR on document. I would really prefer to see these put in place but I know that it will require more time than your proposal.
Again, for me just fixing the import of XARs with PR pages is not satisfactory.
But we live with not fixed ones since so long, that it should be our first steps before anything else IMHO.
We need to be able to detect quickly when a feature/app/script is broken because it misses it's programming right, for whatever reason it misses it.
If you really want that, this could be a extension that you may build on comparing XAR with living applications. I agree that this could be a little bit more trickier, but it have the double advantage of not adding new meta-information and not being a core panel that impact all applications. This addition of new informations without any guarantee that these informations are reflecting the true reality of access rights, is for me going in the wrong direction and increasing complexity of the issue. Once your panel is in place, and it based its conclusion on possibly missing informations (old page imported in a previous version), user will complains even more. Using the contentAuthor field of initial XAR used for import to provide the same panel is probably more reliable and backward compatible.
I don't agree with the more reliable here. It might be in your case, but you can't assume that's the general case.
This leads to some questions: 1) What would be the interface of your panel ? (important to be careful on clarity) 2) What would you present for pages that have PR and no meta information saying it require it ?
For me that does not exist :) That's potentially ALL pages in the default install. I don't think we have to manage that case.
3) What would you present for pages that haven't PR but meta information requiring it ?
It would offer a button to fix it, granted the administrator has the programming right. This makes me think we could offer the UI (in the programming section for example) only to users with programming access level, since they are the only one who can act upon such problems. That would not increase the complexity for local admins, but provide good tooling for farm admins. I agree it's a bit touchy as a design choice, though. WDYT ? More generally, I think I can come soon with a simple prototype, for example on the incubator. There isn't too much work involved for a demonstrator.
I hope you can reconsider your "almost veto".
So to resume what I dislike:
1) it adds a new admin panel that increase the overall complexity of XWiki, could not it be optional ? 2) it require additional informations to deduce the needs of PR, which may be absent in migrating XWikis, and could result in the reverse of what we are trying to fix; but increasing the complexity of the issue.
I will not veto if no one else does but I would be happy the ear comments from others on my comments.
Thank you for expressing your view, I hope too we can hear more comments from others on the topic. Jerome.
Denis
Jerome.
Denis
Jerome.
Sorry for these late comments (and please do not feel hurt by them ;)
),
I
have missed the initial thread.
Denis
If we agree I volunteer to implement this in 3.0 M2.
Jerome. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Le 24/01/11 17:32, Denis Gervalle a écrit : > >>> 2) Reduce the number of pages requiring PR, by providing non-PR interface >> to >>> function that currently require them (isn't it a goal in progress?) >> 2) I guess we all agree with that >> > nice :) > > Can we actually do that ? Don't WikiMacros require programming rights ? Is that not the cause of more troubles recently, with the home page being broken after import ? If WikiMacros require prog rights, I don't see how we are going to fix the issue anytime soon. Now even if we reduce the number of pages in the default distribution, that does not fix projects were we need it. When we build code that requires programming rights it's usually because we cannot do any other way. Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On 01/27/2011 12:08 AM, Ludovic Dubost wrote: > Le 24/01/11 17:32, Denis Gervalle a écrit : >> >>>> 2) Reduce the number of pages requiring PR, by providing non-PR >>>> interface >>> to >>>> function that currently require them (isn't it a goal in progress?) >>> 2) I guess we all agree with that >>> >> nice :) >> >> > Can we actually do that ? Don't WikiMacros require programming rights ? No, they only require edit rights on the wiki macro document for the _current user when the macro doc is being saved_ (which is usually the author of the document, but not really always, that's what makes it fun ;) ). > Is that not the cause of more troubles recently, with the home page > being broken after import ? if you mean XWIKI-5668, then it doesn't make much difference which of programming or edit are needed. > > If WikiMacros require prog rights, I don't see how we are going to fix > the issue anytime soon. > > Now even if we reduce the number of pages in the default distribution, > that does not fix projects were we need it. > When we build code that requires programming rights it's usually because > we cannot do any other way. > > Ludovic > > > > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs
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<dgl@softec.lu> wrote:
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter<jerome@xwiki.com> 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.
Denis
If we agree I volunteer to implement this in 3.0 M2.
Jerome. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
I agree with this. I mean I like it as an approach that fixes an issue in a relatively harmless way (1 + 2). 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 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 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Jan 27, 2011 at 00:52, Anca Luca <lucaa@xwiki.com> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Hi Denis, On 01/27/2011 09:04 AM, Denis Gervalle wrote:
On Thu, Jan 27, 2011 at 00:52, Anca Luca<lucaa@xwiki.com> 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,
If it's about tricking the admin to save my page with rights, I might as well do that by calling him or by sending him a mail, or by any method. I agree that yes, it's "one more way to trick the admin" but I really don't think this is a security issue specific to this proposal.
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.
Honestly, for the world peace, I hope people are aware of what the rights that they have mean. IIUC, you'd be able to save the page with PR only if you're yourself a programmer, which the admin is not necessarily. So again, I don't think this is a problem specific to this solution, I mean if an admin doesn't know what programming is, I might as well, as a normal user, trick him into giving me that right in the rights interface. I mean really, if we start from the idea that an admin would click any button without thinking what it means, I'll start another thread to desactivate admin account altogether. Of course, we'll do our best in the "PR admin panel", to explain correctly what it means to help people understand the most of what they're doing. But again this should not be specific to this solution. By harmless I meant that it doesn't really modify any security mechanism, or grant any rights or whatever, it's just metadata, it's just an easier way for a guy with programming rights to verify, in a glance, what are the pages on his wiki that require programming rights and handle this issue in an easier way than read the pages from a mail, go through all of them and resave them manually individually. Jerome, so that I don't forget: some very interesting information in the admin panel would be the last author of the script that requires PR as well as the user which added the requirement to the page (the object). Thanks, Anca
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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Jan 27, 2011 at 9:04 AM, Denis Gervalle <dgl@softec.lu> wrote:
On Thu, Jan 27, 2011 at 00:52, Anca Luca <lucaa@xwiki.com> 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.
I don't have strong feelings on this, but for me it could even go in the standard distribution (for example in the administration section). We could show it only for admins with the programming access level (since others cannot act on missing PR), but I'm not so sure it's a good idea. About missing PR "requirement" information, I'm not sure what you propose, since for the moment there is no way you can detect a page requires the PR. So when you say
and for legacy code, a possibility to fix either the PR status of a page, or the requirement of a page.
I don't know what this means. Jerome.
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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Thanks for the answers, I think we've reached a consensus on at least one thing : adding the metadata in pages that require PR. I'm going to implement that for 3.0M2. If nobody opposes it, I will : * Add to the XWiki.RequiredRightClass to XWiki Enterprise xar (I think it makes more sense in XE than in the admin app), with a single field for now, which precise the right the page must be saved with. Multiselect with 2 values for now : "programming" and "edit" * Add the object to all pages requiring it. If I miss some, please help me spot them :) The rest can be implemented later, although I will also try to make a quick PoC of the admin UI for offering to fix PR. Jerome. On Wed, Jan 19, 2011 at 8:04 PM, Jerome Velociter <jerome@xwiki.com> 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.
participants (7)
-
Anca Luca -
Denis Gervalle -
Guillaume Lerouge -
Jerome Velociter -
Ludovic Dubost -
Sergiu Dumitriu -
Vincent Massol