16 Mar
2010
16 Mar
'10
10:03 a.m.
On Tue, Mar 16, 2010 at 03:46, Caleb James DeLisle <calebdelisle(a)lavabit.com
wrote:
Right now a script which is saved with programming
access is allowed to do
things which
the viewer (who executes it) is not allowed to do. I would like to extend
this to scripts which do not
have programming access.
Use case example:
A page where the viewer can submit an email address to be put on a mailing
list. The page needs to be able to
save the email address to a list but the viewer should not be able to
directly edit (or view) the list.
I would like to add to xwiki.api.Context:
void setScriptUser(String)
String getScriptUser()
(These names are the best I could think of, suggestions would be great)
the input can be either "viewer", "author" or "default" and
it stores this
in the XWikiContext
If the value is set to author, hasAccessLevel will return an access check
on the author, not the viewer.
When includeForm is called, or the include macro is invoked, the only
explicit change is that changes made by
the called document will be reset when the include ends.
If scrips are set to run with author's permissions:
If DocumentA includes documentB, documentB executes with documentB's
author's permissions.
If DocumentA includes _in context_ documentB, documentB executes with
documentA's author's permissions.
When include of documentB ends, scriptUser is set back to the value which
documentA left it at.
I think this will help us achieve the goal of no documents with programming
rights in the XE xar file.
WDYT?
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
First of all, I am personally against adding anything to the RightService in
its current state. This is already spaghetti code which already lead to some
security risks, and trying to improve that partly could be an impossible
challenge. Moreover, this code is absolutely not optimized, you just have to
put it under debug logging to understand what I mean.
Regarding the way you expect the inclusion of documents to function, I am
not convince that this is the right choice. The behavior of inclusion has
been broken since Syntax 2.0 has been introduced, and I have always feel
this to be a serious regression. My principal use case is a document (that
could have been created by a user) editable by a user, and that store
objects in itself, and use an inclusion in context for its content. In this
case, the user may save the document, which should therefore be without any
special rights, but the code may need to have higher privileges, and still
require to be included in context for access to the including documents.
This is the typical Sheet case shown in many sample of XWiki Programming,
but with programming right requirement. I have used that many times before
it became broken, and this design is still missing to me.
I am convince that the rights given to a block of code should be tightly
linked to the content author of its containing document, and absolutely not
based on any author in the context in which it is executed. This has been
broken in Syntax 2.0, and this currently leads to elevation of privilege
through inclusions. For the same reason, I do not follow Alex on the idea
that the right should be set in place of a user. This would lead to many
problem in regards of who and how this could be set, stored and inherited.
I completely agree that the programming right is currently not perfect, but
in the same time, I do not see the real value you expect to provide. There
is already a similar mechanism in place, using the content author, opposed
to the last author of a page. This is what make commenting page possible
without breaking its programming behavior. Extending this to manage other
objects in my use case above, is probably a good track to follow. But again,
this should be part of a global reengineering of the RightService.
If you want to rethink the RightService starting from scratch, I will surely
participate ! I have already some ideas, but not been able to put them
properly in a document. Time is always missing, but I hope this to change...
Regards,
Denis
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO