22 Mar
2010
22 Mar
'10
6:57 p.m.
Right now I'm working on an email invitation script, It is supposed to store emails
so that in the event that a recipient reports an email as spam, the message will be
available for review by the administrator.
The script must be able to save objects to a document which the user cannot save.
I am left with the options of making the email a comment and posting it to the page
and hoping the user does not submit a bunch of fake comments, or adding an api to
save a document with the security context of the scripts's author.
So I would like to once again push the idea of adding:
Document.saveAsAuthor() which will switch the user in the XWikiContext to the script
author, save the document, then switch the user in context back to the viewer.
and
XWiki.getDocumentAsAuthor() which will do the same but call getDocument instead.
I would also like to add a configuration parameter to xwiki.cfg (these changes are
in the old core) which will switch the new functions between using the contentAuthor
which is more versatile and using the author which is safer.
WDYT?
Caleb
Caleb James DeLisle wrote:
Denis Gervalle wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Mar 17, 2010 at 10:29, Caleb James
DeLisle <calebdelisle(a)lavabit.com
It would be the document in the context which (we hope) is the document containing
the code being executed. This is the same way that hasProgrammingRights works.
The security could be improved by throwing an error if
context.get("isInRenderingEngine")
does not return Boolean.TRUE.
Caleb
wrote:
After realizing that it would be a huge pain to prevent the author being
set to the
viewer on document save I would like to propose this:
api.Document.saveAsContentAuthor()
api.XWiki.getDocumentAsContentAuthor(String Space, String Name)
The names are relatively self explanatory, They
will act like the normal
load and save
methods but checking rights on the document's content author instead of the
viewer.
Sorry, but I really need some more explanation, which document ? the content
author of which document ? If these prove safe and useful then we could look
into adding rename and
delete later.
Cannot say if it is useful or safe, it depends on the interpretation I made
of your proposal. For sure, it could became very unsafe depending on the
implementation!
Denis
WDYT?
Caleb
Caleb James DeLisle wrote:
Vincent Massol wrote:
> On Mar 16, 2010, at 12:52 PM, Caleb James DeLisle wrote:
>
>> Vincent Massol wrote:
>>> On Mar 16, 2010, at 11:08 AM, Caleb James DeLisle wrote:
>>>
>>>> Denis Gervalle wrote:
>>>>> 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.
>>>> +1 I read it and I know exactly what you mean, I *think* a rights
check could be done
>>>> in one query.
>>>>
>>>> I was only talking about modifying api.Context and api.Api I have no
desire to touch
>>>> user.impl.xwiki.ANYTHING!
>>>>
>>>>> 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.
>>>> You bring up an important point which I think is worthy of it's own
email. I have thought
>>>> it would be nice to allow PR code
to extend the api or to add
velocity macros
>>>> which will run with programming
right.
>>>>
>>>>> I am convince that the rights given to a block of code should be
tightly
>>>>> linked to the content author
>>>> I hereby ammend my proposal to include contentAuthor as a possibility
for the set method, I had
>>>> forgotten about it.
>>>>
>>>>> of its containing document, and absolutely not
>>>>> based on any author in the context in which it is executed.
>>>> Do you mean the viewer? I believe code should never be executed in
context of it's viewer
>>>> because code may set a trap which
saves itself when the viewer has
greater privileges than the
>>>> code. I propose the set method
because I am -1 to changing default
behavior.
>>>>> 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.
>>>> I want to extend that same mechanism to authors who do not have
programming rights,
>>>> PR is dangerous and should be
used as little as possible and if we
need it in the default
>>>> xar that is an API flaw IMO.
>>>>
>>>>> 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...
>>>> I absolutely do want to rethink
the RightService, however I think it
is held up by the fact
>>>> that components have no access to
the HttpServletRequest.
>>> Just answering this last point. This is not quite true. Components do
have access to the Container component which represents the environment.
>> Getting the HttpServletRequest requires
an if instanceof cast hack.
Case in point Request, Response and Session are not
used anywhere in the
core.
>>> However, I don't think it's
good that the authentication service
relies on it. What do you need exactly from
the request? You should expose
that need in the Execution Context.
>> For simple form/cookie authentication the
cookies, request parameters,
and maybe the user agent and ip address for a
"nothing up my sleeve" hash
should suffice.
>> For foaf+ssl, I suspect request headers
will be needed and some way to
prove that it is in fact https.
>> I'm not sure what openId will need.
>> If we are to continue using org.securityfilter we must pass it a full
httpServletRequest.
>>> For example imagine that you need
some unique id representing the
session. If so, then this could be stored in the EC
directly or through a
more coarsed-grained object.
>>> This would allow the authentication
service to work in different
environments: servlet, portlet, deamon threads, etc.
>> In the case of daemon threads we can
either make them craft a dummy
HttpServletRequest or we make them conform to a
standard which we invent (x,
y and z must be in the ExecutionContext).
>> I don't like seeing component
implementations become dependent on their
container but it bothers me to see new
code go into the old core because the
necessary resources are hidden and exposing them is politically too
difficult.
>>> The other option (maybe even better)
is to authenticate the user at
the level of the environment, i.e. in Container
implementations. And the
output of the environment level would be to have a User object put in the
Execution Context. I feel this second option is even better than the first
since it works without introducing an additional variable in the EC and
after all the authentication is related to the environment to some degree.
>> If I understand you right this would and
preclude advanced
authentication such as foaf+ssl or openid which is not supported
by the
environment.
>> I also seem to remember hearing that
tomcat was mangling session ids
(users becoming logged in as someone else.)
>> I propose that we make available the
actual request, response and
session using generics instead of the casting trick
then we make it a best
practice to avoid using them unless necessary.
> Adding new methods to the XWiki session,
request and response is ok and
is easy to do. The problem is that once you get past
the environment ring,
no component should access the environment anymore as otherwise it makes
these components work only in a specific environment.
> Here's what I mean:
> http://tinycoke.com/_6rr5a0xjRU7Xg/architecture-layers.png
I agree with the line of thinking, the question is how to express that in
the
code.
I imagine the xwiki-authentication directory
containing:
xwiki-authentication-api
and
xwiki-authentication-servlet-openid
and so on.
Another thought is it would be helpful to provide utility interfaces
which extend
both portlet and servlet request, response and session.
This would allow for component implementations
which can support both.
How about that?
Caleb
> wdyt?
>
> Thanks
> -Vincent
>
> _______________________________________________
> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs