20 Jan
2011
20 Jan
'11
2:22 p.m.
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