19 Jan
2011
19 Jan
'11
8:04 p.m.
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.
20 Jan
20 Jan
12:36 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
Hi Jérôme,
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:10 p.m.
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.
2:22 p.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
On Thu, Jan 20, 2011 at 1:10 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi Jerome,
On Jan 19, 2011, at 8:04 PM, Jerome Velociter wrote:
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
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).
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?
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.
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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
24 Jan
24 Jan
12:14 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
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/
9:38 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
9:56 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
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.
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.
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter
<jerome(a)xwiki.com> wrote:
Well, if you are working around them for so long, then I don't
understand why you've not proposed a patch before ;)
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.
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.
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 ?
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:23 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
On Mon, Jan 24, 2011 at 09:56, Jerome Velociter <jerome(a)xwiki.com> wrote:
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.
the
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.
I
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.
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
On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle
<dgl(a)softec.lu> wrote:
so
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. ;)
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter
<jerome(a)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 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 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.
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, 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.
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Sorry for these late comments (and please do not feel hurt by them ;) ),
I
have missed the initial thread.
Denis
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
If we agree I volunteer to implement this in 3.0 M2.
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:08 p.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
On Mon, Jan 24, 2011 at 11:23 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Mon, Jan 24, 2011 at 09:56, Jerome Velociter
<jerome(a)xwiki.com> wrote:
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.
the
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.
I
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.
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.
On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle
<dgl(a)softec.lu> wrote:
so
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. ;)
On Wed, Jan 19, 2011 at 20:04, Jerome Velociter
<jerome(a)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 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 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.
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, 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 ?
Denis
Jerome.
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Sorry for these late comments (and please do not feel hurt by them ;) ),
I
have missed the initial thread.
Denis
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
If we agree I volunteer to implement this in 3.0 M2.
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:32 p.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
On Mon, Jan 24, 2011 at 16:08, Jerome Velociter <jerome(a)xwiki.com> wrote:
On Mon, Jan 24, 2011 at 11:23 AM, Denis Gervalle
<dgl(a)softec.lu> wrote:
XWiki.Admin
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
PR.
xwiki:XWikiAdmin
Well, I could not disagree, but why should you explain PR in first place ?
1) I propose that initial and application XARs are properly built to put PR
Well, but this is the use case that cause most trouble in a farm currently.
On Mon, Jan 24, 2011 at 09:56, Jerome Velociter
<jerome(a)xwiki.com>
wrote:
> On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
> > On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome(a)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
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 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
> > 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.
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
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 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.
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 ?
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
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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Denis
>
> Jerome.
>
> >
> > Sorry for these late comments (and please do not feel hurt by them ;)
),
I
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
have missed the initial thread.
Denis
>
> If we agree I volunteer to implement this in 3.0 M2.
>
> Jerome.
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
26 Jan
26 Jan
10:18 p.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
On Mon, Jan 24, 2011 at 5:32 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
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.
Thank you for expressing your view, I hope too we can hear more
comments from others on the topic.
Jerome.
On Mon, Jan 24, 2011 at 16:08, Jerome Velociter
<jerome(a)xwiki.com> wrote:
That's a good idea.
On Mon, Jan 24, 2011 at 11:23 AM, Denis Gervalle
<dgl(a)softec.lu> wrote:
XWiki.Admin
that
PR.
xwiki:XWikiAdmin
?
PR
Well, but this is the use case that cause most trouble in a farm currently.
On Mon, Jan 24, 2011 at 09:56, Jerome Velociter
<jerome(a)xwiki.com>
wrote:
> On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
> > On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome(a)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 > 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 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
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 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 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
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 ?
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.
Denis
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
27 Jan
27 Jan
12:08 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
Le 24/01/11 17:32, Denis Gervalle a écrit :
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
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
12:30 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
On 01/27/2011 12:08 AM, Ludovic Dubost wrote:
Le 24/01/11 17:32, Denis Gervalle a écrit :
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
;) ).
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
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:08 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
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(a)softec.lu> wrote:
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.
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.
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On Wed, Jan 19, 2011 at 20:04, Jerome
Velociter<jerome(a)xwiki.com> wrote:
Well, if you are
working around them for so long, then I don't
understand why you've not proposed a patch before ;)
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.
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. 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 ?
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
If we agree I volunteer to implement this in 3.0
M2.
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:52 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:04 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
On Thu, Jan 27, 2011 at 00:52, Anca Luca <lucaa(a)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:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:47 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
Hi Denis,
On 01/27/2011 09:04 AM, Denis Gervalle wrote:
On Thu, Jan 27, 2011 at 00:52, Anca
Luca<lucaa(a)xwiki.com> wrote:
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.
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.
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3 Feb
3 Feb
11:56 a.m.
New subject: [xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
On Thu, Jan 27, 2011 at 9:04 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Thu, Jan 27, 2011 at 00:52, Anca Luca
<lucaa(a)xwiki.com> wrote:
on
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 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.
legacy
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 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 !
the
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 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
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
noon
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(a)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.
5023
days inactive
5038
days old
18 comments
7 participants
participants (7)
-
Anca Luca -
Denis Gervalle -
Guillaume Lerouge -
Jerome Velociter -
Ludovic Dubost -
Sergiu Dumitriu -
Vincent Massol