[xwiki-devs] [Proposal] Add api to allow scripts choose with the permission of their author.
16 Mar
2010
16 Mar
'10
3:46 a.m.
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
16 Mar
16 Mar
5:19 a.m.
On 03/16/2010 03:46 AM, Caleb James DeLisle wrote:
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.
What would happen if the access rights of user A who ones wrote several
scripts with script user = "author" would change (e.g. if admin would
revoke A's programming rights)?
IMO it would be better to set the execution rights explicitly, i.e.
"view", "edit", "admin" etc. It is more robust and would
also allow to
set only the rights that are really needed (e.g. "edit" instead of
"admin" if the author is administrator).
Of course, one would need to check on save, that the requested rights
are not higher than the rights of the author.
In any case, I think the name "setExecutionRights(String)" is better,
because if the script user is "author", it sounds (at least to me) as if
nobody else is allowed to use it.
Alex
11:14 a.m.
Alex Busenius wrote:
On 03/16/2010 03:46 AM, Caleb James DeLisle wrote:
Unless there was a change to the rights model
the scripts would stop working.
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.
What would happen if the access rights of user A who ones wrote several
scripts with script user = "author" would change (e.g. if admin would
revoke A's programming rights)?
IMO it would be better to set the execution rights explicitly, i.e.
"view", "edit", "admin" etc. It is more robust and would
also allow to
set only the rights that are really needed (e.g. "edit" instead of
"admin" if the author is administrator).
Of course, one would need to check on save, that the requested rights
are not higher than the rights of the author.
Currently rights are checked on view
which is slower but safer. Shedding rights (sandboxing code)
is an idea which has been discussed before, the problem as I see it is how do we prevent a
script
from asking the same APIs for more rights.
I agree the ability to sandbox code is a necessity but I think it needs to look more like
evaluateCodeWithReducedPermission(String code, Set<Permission> permissionsToDeny)
In any case, I think the name "setExecutionRights(String)" is better,
I'm not quite sold on that name because ExecutionRights tells me it's a
"what" and my proposal is
about a "who" as in "execute with who's access privilages?"
Caleb
because if the script user is "author", it
sounds (at least to me) as if
nobody else is allowed to use it.
Alex
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:03 a.m.
New subject: [xwiki-devs] [Proposal] Add api to allow scripts choose with the permission of their author.
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
11:08 a.m.
Denis Gervalle wrote:
On Tue, Mar 16, 2010 at 03:46, Caleb James DeLisle
<calebdelisle(a)lavabit.com
+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!
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.
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.
Caleb
Regards,
Denis
11:09 a.m.
New subject: [xwiki-devs] [Proposal] Add api to allow scripts choose with the permission of their author.
On Mar 16, 2010, at 11:08 AM, Caleb James DeLisle wrote:
Denis Gervalle wrote:
Just answering this last point. This is not quite true. Components do have access to the
Container component which represents the environment. 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 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.
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.
WDYT?
Thanks
-Vincent
On Tue, Mar 16, 2010 at 03:46, Caleb James
DeLisle <calebdelisle(a)lavabit.com
+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!
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.
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.
12:52 p.m.
Vincent Massol wrote:
On Mar 16, 2010, at 11:08 AM, Caleb James DeLisle
wrote:
Getting the HttpServletRequest
requires an if instanceof cast hack. Case in point Request, Response and Session are not
used anywhere in the core.
Denis Gervalle wrote:
Just answering this last point. This is not quite true. Components do have access to the
Container component which represents the environment. On Tue, Mar 16, 2010 at 03:46, Caleb James
DeLisle <calebdelisle(a)lavabit.com
+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!
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.
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. 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.
WDYT?
Caleb
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:07 p.m.
New subject: [xwiki-devs] [Proposal] Add api to allow scripts choose with the permission of their author.
On Mar 16, 2010, at 12:52 PM, Caleb James DeLisle wrote:
Vincent Massol wrote:
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
wdyt?
Thanks
-Vincent
On Mar 16, 2010, at 11:08 AM, Caleb James DeLisle
wrote:
Getting the
HttpServletRequest requires an if instanceof cast hack. Case in point Request, Response
and Session are not used anywhere in the core.
Denis Gervalle wrote:
Just answering this last point. This is not quite true. Components do have access to the
Container component which represents the environment. 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. 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. 
1:34 p.m.
Vincent Massol wrote:
On Mar 16, 2010, at 12:52 PM, Caleb James DeLisle
wrote:
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
Vincent Massol wrote:
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 On Mar 16, 2010, at 11:08 AM, Caleb James DeLisle
wrote:
Getting the HttpServletRequest requires an if
instanceof cast hack. Case in point Request, Response and Session are not used anywhere in
the core.
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. 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.
wdyt?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
17 Mar
17 Mar
10:29 a.m.
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.
If these prove safe and useful then we could look into adding rename and delete later.
WDYT?
Caleb
Caleb James DeLisle wrote:
Vincent Massol wrote:
On Mar 16, 2010, at 12:52 PM, Caleb James DeLisle
wrote:
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
Vincent Massol wrote:
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 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. 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
10:35 a.m.
New subject: [xwiki-devs] [Proposal] Add api to allow scripts choose with the permission of their author.
On Wed, Mar 17, 2010 at 10:29, Caleb James DeLisle <calebdelisle(a)lavabit.com
> 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
> >>>>>> >
>>>>>>> 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
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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)
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.
> >>>>>>
11:22 a.m.
Denis Gervalle wrote:
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:
the code.
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 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
22 Mar
22 Mar
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
23 Mar
23 Mar
9:13 a.m.
New subject: [xwiki-devs] [Proposal] Add api to allow scripts choose with the permission of their author.
On Mon, Mar 22, 2010 at 18:57, Caleb James DeLisle <calebdelisle(a)lavabit.com
wrote:
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.
Well, I am not sure this is the proper way to do so. Switching user will in
fact also change the author that is doing the save, and therefore loose any
information about the real author of the change, something the current API
currently prevent. Wouldn't it be better to just do something similar to
saveWithProgrammingRight(), by simply checking edit right against the
content author, and proceed to the normal saveDocument() ?
and
XWiki.getDocumentAsAuthor() which will do the same but call getDocument
instead.
For this one, checking against the content author, that the document is
viewable could be enough as well, avoiding a useless context switch, no ?
With the above remarks, I see no real inconvenience to have these two
functions added in the old API, since it fit well with the saveWithPR one.
It could reduce the need of PR which is always welcome.
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.
I do not agree that the author could be safer. Both have issues.
Do you really need this ?
Denis
> WDYT?
>
>
> Caleb
>
>
>
> Caleb James DeLisle wrote:
> >
> > Denis Gervalle wrote:
> >> On Wed, Mar 17, 2010 at 10:29, Caleb James DeLisle <
> calebdelisle(a)lavabit.com
> >> 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 ?
> >
> > 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
> >
> >>
> >>> 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
> >>>
> >>
> >>
> >
> > _______________________________________________
> > 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
17 Mar
17 Mar
9:59 a.m.
New subject: [xwiki-devs] [Proposal] Add api to allow scripts choose with the permission of their author.
On Tue, Mar 16, 2010 at 11:08, Caleb James DeLisle <calebdelisle(a)lavabit.com
This is not exactly what I am saying, I hate the idea that code became
broken when an unpriviledged user have just save its container without being
able to change the code itself. This is currently what happen with
inclusion, the user may have no right to change the included document, but
it break the code by just saving the document that make the inclusion. This
is what I means when I say that the privilege of a script should be tightly
linked to who has been able to write it. As a helper mechanism, a script may
offered the possibility to release its privilege based on the user using it,
but it could not raise it, since this could lead to major security issues,
and this release should be the choice of the script author.
Making PR more fine grained is for me a task for the RightService not the
API.
Moreover, extending that without thinking about the whole access policy is
risky and will create problem for future compatibility.
I do not agree. Are you sure that you do not confuse authentication and
authorization ? It is still hard to review the authentication part, and this
one needs to be extensible and partly depends on the container. For
authentication, I really like the modularity of Acegi Security (aka Spring
Security) model (the model, not the implementation as is), which provide a
good separation of each roles, allowing easy integration of many way to
provide authentications. Authentication should provide a token identifying a
user and what are the "global" privileges allowed to this token (group
ownership, admin privileges, ???). It should be able to do so for the
connected user, and also for a stored token saved with a document (ie the
author of a document). It could base its information from many different
sources, coming either from the wiki or external to it. It may also provide
directory services to the wiki.
The authorization part is on the other side and should be independent of the
container or any other external stuffs, and, of course, the way we
authenticate users. The communication between the two module should be
through some sort of token, that the authentication module ask to the
authorization module when needed. Asking could be for the current
authenticated user, using an existing persisted token or be built
temporarily as a mixed of other tokens for controlling a given script
execution. This second part has to be called anytime a privileged operation
has to be done on a given object. The caller should normally not tell what
he really want to check, but just what operation he want to do on which
"object". This is the task of the authorization module to know what to check
and this is precisely why I dislike continuing to add some sort of "check
this right on this user" anymore.
Well, this is quick and dirty description of what I feel is needed for
proper and secure right checking, obviously easier to say than to do. But I
feel the work could be started, especially on the authorization part, using
some bridging when require. It will be long, but I really think that it is
the price to pay for getting something really secure.
Denis
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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 have read it as well, and you may find a document I have written in the
drafts of XWiki.org about how it is currently working. But anyway, look at
the debug logs even after looking the code, you understand that it even
worse than you think.
I was only talking about modifying api.Context and
api.Api I have no desire
to touch
user.impl.xwiki.ANYTHING!
Isn't this moving some of the RightService responsibility out of it ? I am
already unhappy with how access are checked, since, these check are not only
in the right service, but also in many other part of the core, checking
special cases, like skin access, inactive user check, etc....
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.
11:37 a.m.
New subject: [xwiki-devs] [Discussion] New authorization module. was: Re: [Proposal] Add api to allow scripts choose with the permission of their author.
Denis Gervalle wrote:
On Tue, Mar 16, 2010 at 11:08, Caleb James DeLisle
<calebdelisle(a)lavabit.com
This is not exactly what I am saying, I hate the idea that code became
broken when an unpriviledged user have just save its container without being
able to change the code itself. This is currently what happen with
inclusion, the user may have no right to change the included document, but
it break the code by just saving the document that make the inclusion. This
is what I means when I say that the privilege of a script should be tightly
linked to who has been able to write it. As a helper mechanism, a script may
offered the possibility to release its privilege based on the user using it,
but it could not raise it, since this could lead to major security issues,
and this release should be the choice of the script author.
Making PR more fine grained is for me a task for the RightService not the
API.
Moreover, extending that without thinking about the whole access policy is
risky and will create problem for future compatibility.
I do not agree. Are you sure that you do not confuse authentication and
authorization ?
Yes I suppose I did, so much talk about foaf+ssl and openId, I have
been thinking
too much about authentication. Still I think they should both be rewritten at once.
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 have read it as well, and you may find a document I have written in the
drafts of XWiki.org about how it is currently working. But anyway, look at
the debug logs even after looking the code, you understand that it even
worse than you think.
I was only talking about modifying api.Context
and api.Api I have no desire
to touch
user.impl.xwiki.ANYTHING!
Isn't this moving some of the RightService responsibility out of it ? I am
already unhappy with how access are checked, since, these check are not only
in the right service, but also in many other part of the core, checking
special cases, like skin access, inactive user check, etc....
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.
It is still hard to review the authentication part,
and this
one needs to be extensible and partly depends on the container. For
authentication, I really like the modularity of Acegi Security (aka Spring
Security) model (the model, not the implementation as is), which provide a
good separation of each roles, allowing easy integration of many way to
provide authentications. Authentication should provide a token identifying a
user and what are the "global" privileges allowed to this token (group
ownership, admin privileges, ???). It should be able to do so for the
connected user, and also for a stored token saved with a document (ie the
author of a document). It could base its information from many different
sources, coming either from the wiki or external to it. It may also provide
directory services to the wiki.
The authorization part is on the other side and should be independent of the
container or any other external stuffs,
Here we have the trouble of dependence on
the user class, rights class, and objects.
I see this in core java code:
private static final String USER_CLASS = "XWiki.XWikiUsers";
as an eye sore and would like to remove it if possible.
Another alternative is to move that kind of ugliness it out to a configuration file.
and, of course, the way we
authenticate users. The communication between the two module should be
through some sort of token, that the authentication module ask to the
authorization module when needed. Asking could be for the current
authenticated user, using an existing persisted token or be built
temporarily as a mixed of other tokens for controlling a given script
execution. This second part has to be called anytime a privileged operation
has to be done on a given object. The caller should normally not tell what
he really want to check, but just what operation he want to do on which
"object". This is the task of the authorization module to know what to check
and this is precisely why I dislike continuing to add some sort of "check
this right on this user" anymore.
I guess I don't understand, the way I
see it an authorization check must check the
permission for entity (user) x to do action y to object z.
Well, this is quick and dirty description of what I feel is needed for
proper and secure right checking, obviously easier to say than to do. But I
feel the work could be started, especially on the authorization part, using
some bridging when require. It will be long, but I really think that it is
the price to pay for getting something really secure.
Long as in a lot of code? I
feel that security (and dependability) require the code
to be short and if it can't be short, isolate the code which runs 90% of the time
and try to make that short.
Caleb
Denis
5:20 p.m.
New subject: [xwiki-devs] [Discussion] New authorization module. was: Re: [Proposal] Add api to allow scripts choose with the permission of their author.
On Wed, Mar 17, 2010 at 11:37, Caleb James DeLisle <calebdelisle(a)lavabit.com
I do not fully agree. An authorization check should check that a certain
operation could be executed in the current context on a given entity.
Let say that you want to delete a given document, you need to check that you
can do so now in your execution context, but I really feel that the
conditions to answer your right request should be only the responsibility of
the authorization module. In the non-security code, you should only request
privilege for an operation, and not thinking carefully about what are the
proper conditions for it.
Not that I voluntarily do not talk about users, since I would like to be
able to execute a script in the context of an authentication token having
less privilege than it has at the startup of the script. Tokens are like
keychains for your house. You may have the key, or you may have drop it, it
depends. You may also gain it in some special situation.
Not long code, but short and well formed one should be required. Nice
interface and component will lead to a really better implementation anyhow.
What could be long is the process to agree on the principle and to also
agree on the implementation. This is just ambitious.
Denis
wrote:
>
>
> Denis Gervalle wrote:
> > On Tue, Mar 16, 2010 at 11:08, Caleb James DeLisle <
> calebdelisle(a)lavabit.com
> > 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 have read it as well, and you may find a document I have written in the
> > drafts of XWiki.org about how it is currently working. But anyway, look
> at
> > the debug logs even after looking the code, you understand that it even
> > worse than you think.
> >
> >
> >> I was only talking about modifying api.Context and api.Api I have no
> desire
> >> to touch
> >> user.impl.xwiki.ANYTHING!
> >>
> >
> > Isn't this moving some of the RightService responsibility out of it ? I
> am
> > already unhappy with how access are checked, since, these check are not
> only
> > in the right service, but also in many other part of the core, checking
> > special cases, like skin access, inactive user check, etc....
> >
> >
> >>> 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.
> >
> >
> > This is not exactly what I am saying, I hate the idea that code became
> > broken when an unpriviledged user have just save its container without
> being
> > able to change the code itself. This is currently what happen with
> > inclusion, the user may have no right to change the included document,
> but
> > it break the code by just saving the document that make the inclusion.
> This
> > is what I means when I say that the privilege of a script should be
> tightly
> > linked to who has been able to write it. As a helper mechanism, a script
> may
> > offered the possibility to release its privilege based on the user using
> it,
> > but it could not raise it, since this could lead to major security
> issues,
> > and this release should be the choice of the script author.
> >
> >
> >
> >
> >>> 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.
> >>
> >
> > Making PR more fine grained is for me a task for the RightService not the
> > API.
> > Moreover, extending that without thinking about the whole access policy
> is
> > risky and will create problem for future compatibility.
> >
> >
> >>> 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.
> >>
> >
> > I do not agree. Are you sure that you do not confuse authentication and
> > authorization ?
> Yes I suppose I did, so much talk about foaf+ssl and openId, I have been
> thinking
> too much about authentication. Still I think they should both be rewritten
> at once.
>
> > It is still hard to review the authentication part, and this
> > one needs to be extensible and partly depends on the container. For
> > authentication, I really like the modularity of Acegi Security (aka
> Spring
> > Security) model (the model, not the implementation as is), which provide
> a
> > good separation of each roles, allowing easy integration of many way to
> > provide authentications. Authentication should provide a token
> identifying a
> > user and what are the "global" privileges allowed to this token
(group
> > ownership, admin privileges, ???). It should be able to do so for the
> > connected user, and also for a stored token saved with a document (ie the
> > author of a document). It could base its information from many different
> > sources, coming either from the wiki or external to it. It may also
> provide
> > directory services to the wiki.
> >
> > The authorization part is on the other side and should be independent of
> the
> > container or any other external stuffs,
> Here we have the trouble of dependence on the user class, rights class, and
> objects.
> I see this in core java code:
> private static final String USER_CLASS = "XWiki.XWikiUsers";
> as an eye sore and would like to remove it if possible.
> Another alternative is to move that kind of ugliness it out to a
> configuration file.
This should not happen anymore, since for me, users and their privilege and
groups, should be provided by the authentication part. Synchronizing 2
directory is always a pain, so this should be avoided. So I would expect
that a proper authentication module will provide all the answer for the
authorization module, regarding the authenticated user, which means that an
LDAP user will not need to be stored in the XWikiUsers anymore.
and, of
course, the way we
authenticate users. The communication between the two module should be
through some sort of token, that the authentication module ask to the
authorization module when needed. Asking could be for the current
authenticated user, using an existing persisted token or be built
temporarily as a mixed of other tokens for controlling a given script
execution. This second part has to be called anytime a privileged
operation
has to be done on a given object. The caller
should normally not tell
what
he really want to check, but just what operation
he want to do on which
"object". This is the task of the authorization module to know what to
check
and this is precisely why I dislike continuing to
add some sort of "check
this right on this user" anymore.
I guess I don't understand, the way I
see it an authorization check must
check the
permission for entity (user) x to do action y to object z.
Well, this is quick and dirty description of what I feel is needed for
proper and secure right checking, obviously easier to say than to do. But
I
feel the work could be started, especially on the
authorization part,
using
some bridging when require. It will be long, but
I really think that it
is
the price to pay for getting something really
secure.
Long as in a lot of code? I feel that security (and dependability) require
the code
to be short and if it can't be short, isolate the code which runs 90% of
the time
and try to make that short.
Caleb
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Denis
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5294
days inactive
5301
days old
16 comments
4 participants
participants (4)
-
Alex Busenius -
Caleb James DeLisle -
Denis Gervalle -
Vincent Massol