[xwiki-devs] Sheets and programming rights
Hi devs, I need your feedback regarding two use cases: (A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR Drop permissions when rendering the sheet, right? (B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR How often did you write class/document sheets requiring programming rights? I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights. WDYT? Thanks, Marius
Off the top of my head: On 08/31/2011 10:16 AM, Marius Dumitru Florea wrote:
Hi devs,
I need your feedback regarding two use cases:
(A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR
Drop permissions when rendering the sheet, right?
it only seems normal to me too...
(B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR
How often did you write class/document sheets requiring programming rights?
The pb is not how often, but if there's one usecase and we'd make it impossible by this approach, without having a workaround for it. I think there might be cases when you need a sheet with programming rights...
I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights.
I cannot think of usecases right now, but I would make it behave like {{include}} with context=old, because this is the way we used sheets before... (which I think means not having pr for Space2.SheetWithPR) Happy coding, Anca
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Aug 31, 2011 at 11:41 AM, Anca Luca <[email protected]> wrote:
Off the top of my head:
On 08/31/2011 10:16 AM, Marius Dumitru Florea wrote:
Hi devs,
I need your feedback regarding two use cases:
(A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR
Drop permissions when rendering the sheet, right?
it only seems normal to me too...
(B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR
How often did you write class/document sheets requiring programming rights?
The pb is not how often, but if there's one usecase and we'd make it impossible by this approach, without having a workaround for it. I think there might be cases when you need a sheet with programming rights...
I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights.
I cannot think of usecases right now, but I would make it behave like {{include}} with context=old, because this is the way we used sheets before... (which I think means not having pr for Space2.SheetWithPR)
So rendering the Space2.SheetWithPR without programming rights when the target document doesn't have programming rights is acceptable in your opinion right? I suppose that when you create a sheet that requires programming rights you make sure all pages that use that sheet have also programming rights. Thanks, Marius
Happy coding, Anca
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Aug 31, 2011 at 11:08, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Aug 31, 2011 at 11:41 AM, Anca Luca <[email protected]> wrote:
Off the top of my head:
On 08/31/2011 10:16 AM, Marius Dumitru Florea wrote:
Hi devs,
I need your feedback regarding two use cases:
(A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR
Drop permissions when rendering the sheet, right?
it only seems normal to me too...
(B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR
How often did you write class/document sheets requiring programming rights?
The pb is not how often, but if there's one usecase and we'd make it impossible by this approach, without having a workaround for it. I think there might be cases when you need a sheet with programming rights...
I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights.
I cannot think of usecases right now, but I would make it behave like {{include}} with context=old, because this is the way we used sheets before... (which I think means not having pr for Space2.SheetWithPR)
So rendering the Space2.SheetWithPR without programming rights when the target document doesn't have programming rights is acceptable in your opinion right?
I suppose that when you create a sheet that requires programming rights you make sure all pages that use that sheet have also programming rights.
This was an old discussion. In Syntax 1.x, the PR security is based on the document included, and not the including document. This has been changed with the new rendering engine and Syntax 2.x, now the including document is used for checking PR. This does not link tightly the PR with the author of the document (=the only way to determine the author of the script currently), and this is for me the wrong direction. See XWIKI-5027 for more on that. A reason you may want PR for your sheet and not for the including document, is that you'd like to write the sheet in Groovy, while the including document are created by end users. You have opened the pandora box :) Denis
Thanks, Marius
Happy coding, Anca
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Wed, Aug 31, 2011 at 2:39 PM, Denis Gervalle <[email protected]> wrote:
On Wed, Aug 31, 2011 at 11:08, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Aug 31, 2011 at 11:41 AM, Anca Luca <[email protected]> wrote:
Off the top of my head:
On 08/31/2011 10:16 AM, Marius Dumitru Florea wrote:
Hi devs,
I need your feedback regarding two use cases:
(A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR
Drop permissions when rendering the sheet, right?
it only seems normal to me too...
(B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR
How often did you write class/document sheets requiring programming rights?
The pb is not how often, but if there's one usecase and we'd make it impossible by this approach, without having a workaround for it. I think there might be cases when you need a sheet with programming rights...
I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights.
I cannot think of usecases right now, but I would make it behave like {{include}} with context=old, because this is the way we used sheets before... (which I think means not having pr for Space2.SheetWithPR)
So rendering the Space2.SheetWithPR without programming rights when the target document doesn't have programming rights is acceptable in your opinion right?
I suppose that when you create a sheet that requires programming rights you make sure all pages that use that sheet have also programming rights.
This was an old discussion. In Syntax 1.x, the PR security is based on the document included, and not the including document. This has been changed with the new rendering engine and Syntax 2.x, now the including document is used for checking PR. This does not link tightly the PR with the author of the document (=the only way to determine the author of the script currently), and this is for me the wrong direction. See XWIKI-5027 for more on that.
A reason you may want PR for your sheet and not for the including document, is that you'd like to write the sheet in Groovy, while the including document are created by end users.
Exactly. How common is this use case? Can it be implemented in a safe way? Thanks, Marius
You have opened the pandora box :)
Denis
Thanks, Marius
Happy coding, Anca
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Aug 31, 2011 at 2:56 PM, Marius Dumitru Florea <[email protected]> wrote:
On Wed, Aug 31, 2011 at 2:39 PM, Denis Gervalle <[email protected]> wrote:
On Wed, Aug 31, 2011 at 11:08, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Aug 31, 2011 at 11:41 AM, Anca Luca <[email protected]> wrote:
Off the top of my head:
On 08/31/2011 10:16 AM, Marius Dumitru Florea wrote:
Hi devs,
I need your feedback regarding two use cases:
(A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR
Drop permissions when rendering the sheet, right?
it only seems normal to me too...
(B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR
How often did you write class/document sheets requiring programming rights?
The pb is not how often, but if there's one usecase and we'd make it impossible by this approach, without having a workaround for it. I think there might be cases when you need a sheet with programming rights...
I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights.
I cannot think of usecases right now, but I would make it behave like {{include}} with context=old, because this is the way we used sheets before... (which I think means not having pr for Space2.SheetWithPR)
So rendering the Space2.SheetWithPR without programming rights when the target document doesn't have programming rights is acceptable in your opinion right?
I suppose that when you create a sheet that requires programming rights you make sure all pages that use that sheet have also programming rights.
This was an old discussion. In Syntax 1.x, the PR security is based on the document included, and not the including document. This has been changed with the new rendering engine and Syntax 2.x, now the including document is used for checking PR. This does not link tightly the PR with the author of the document (=the only way to determine the author of the script currently), and this is for me the wrong direction. See XWIKI-5027 for more on that.
A reason you may want PR for your sheet and not for the including document, is that you'd like to write the sheet in Groovy, while the including document are created by end users.
Or just modified by end user. Imagine a home page with unstructured content and that somewhere includes a document with a groovy script. You want to keep the ability for users with PR access level to modify the home page, but keep the groovy script isolated in its own document saved by someone with the proper authorization.
Exactly. How common is this use case?
It's a fairly frequent use case IMHO.
Can it be implemented in a safe way?
Thanks, Marius
You have opened the pandora box :)
Denis
Thanks, Marius
Happy coding, Anca
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jerome Velociter Winesquare http://www.winesquare.net/
On Wed, Aug 31, 2011 at 14:56, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Aug 31, 2011 at 2:39 PM, Denis Gervalle <[email protected]> wrote:
On Wed, Aug 31, 2011 at 11:08, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Aug 31, 2011 at 11:41 AM, Anca Luca <[email protected]> wrote:
Off the top of my head:
On 08/31/2011 10:16 AM, Marius Dumitru Florea wrote:
Hi devs,
I need your feedback regarding two use cases:
(A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR
Drop permissions when rendering the sheet, right?
it only seems normal to me too...
(B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR
How often did you write class/document sheets requiring programming rights?
The pb is not how often, but if there's one usecase and we'd make it impossible by this approach, without having a workaround for it. I think there might be cases when you need a sheet with programming rights...
I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights.
I cannot think of usecases right now, but I would make it behave like {{include}} with context=old, because this is the way we used sheets before... (which I think means not having pr for Space2.SheetWithPR)
So rendering the Space2.SheetWithPR without programming rights when the target document doesn't have programming rights is acceptable in your opinion right?
I suppose that when you create a sheet that requires programming rights you make sure all pages that use that sheet have also programming rights.
This was an old discussion. In Syntax 1.x, the PR security is based on the document included, and not the including document. This has been changed with the new rendering engine and Syntax 2.x, now the including document is used for checking PR. This does not link tightly the PR with the author of the document (=the only way to determine the author of the script currently), and this is for me the wrong direction. See XWIKI-5027 for more on that.
A reason you may want PR for your sheet and not for the including document, is that you'd like to write the sheet in Groovy, while the including document are created by end users.
Exactly. How common is this use case? Can it be implemented in a safe way?
If you ask me, I should say that most of the application I have written fall in this case, so it is IMHO really common. This is not a simple issue, and this is not only related to sheets, since it simply concern the include macro, and the way it works. IMHO, the previous behavior (before 2.x), which was to consider the content author of the included document for the PR of its content was safe, as far as the author of that document was aware of that. I have never understand the purpose of the change, which has introduced XWIKI-5027, which is IMO really more difficult to secure when you need to include some other documents (a frequent use case when structuring your code in more than one document for reuse purposes). There have been some discussions about signing scripts to provide PR rights, but this would require wide changes that have been postponed for now. The way PR rights are provided is the Achilles’ heel of XWiki :( If you have full control of the process (being able to choose carefully and you can really choose between the two options), reintroducing the old behavior is for me the way to go. This is what you do when you drop PR for a sheet without PR. So no reason for me to not acquire PR for a sheet with PR. This will be the responsibility of the sheet author to ensure its code is safe in the context of another document. Denis
Thanks, Marius
You have opened the pandora box :)
Denis
Thanks, Marius
Happy coding, Anca
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Wed, Aug 31, 2011 at 5:32 PM, Denis Gervalle <[email protected]> wrote:
On Wed, Aug 31, 2011 at 14:56, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Aug 31, 2011 at 2:39 PM, Denis Gervalle <[email protected]> wrote:
On Wed, Aug 31, 2011 at 11:08, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Aug 31, 2011 at 11:41 AM, Anca Luca <[email protected]> wrote:
Off the top of my head:
On 08/31/2011 10:16 AM, Marius Dumitru Florea wrote:
Hi devs,
I need your feedback regarding two use cases:
(A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR
Drop permissions when rendering the sheet, right?
it only seems normal to me too...
(B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR
How often did you write class/document sheets requiring programming rights?
The pb is not how often, but if there's one usecase and we'd make it impossible by this approach, without having a workaround for it. I think there might be cases when you need a sheet with programming rights...
I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights.
I cannot think of usecases right now, but I would make it behave like {{include}} with context=old, because this is the way we used sheets before... (which I think means not having pr for Space2.SheetWithPR)
So rendering the Space2.SheetWithPR without programming rights when the target document doesn't have programming rights is acceptable in your opinion right?
I suppose that when you create a sheet that requires programming rights you make sure all pages that use that sheet have also programming rights.
This was an old discussion. In Syntax 1.x, the PR security is based on the document included, and not the including document. This has been changed with the new rendering engine and Syntax 2.x, now the including document is used for checking PR. This does not link tightly the PR with the author of the document (=the only way to determine the author of the script currently), and this is for me the wrong direction. See XWIKI-5027 for more on that.
A reason you may want PR for your sheet and not for the including document, is that you'd like to write the sheet in Groovy, while the including document are created by end users.
Exactly. How common is this use case? Can it be implemented in a safe way?
If you ask me, I should say that most of the application I have written fall in this case, so it is IMHO really common.
This is not a simple issue, and this is not only related to sheets, since it simply concern the include macro, and the way it works. IMHO, the previous behavior (before 2.x), which was to consider the content author of the included document for the PR of its content was safe, as far as the author of that document was aware of that. I have never understand the purpose of the change, which has introduced XWIKI-5027, which is IMO really more difficult to secure when you need to include some other documents (a frequent use case when structuring your code in more than one document for reuse purposes). There have been some discussions about signing scripts to provide PR rights, but this would require wide changes that have been postponed for now. The way PR rights are provided is the Achilles’ heel of XWiki :(
If you have full control of the process (being able to choose carefully and you can really choose between the two options), reintroducing the old behavior is for me the way to go.
This is what you do when you drop PR for a sheet without PR. So no reason for me to not acquire PR for a sheet with PR. This will be the responsibility of the sheet author to ensure its code is safe in the context of another document.
The code I'm testing right now checks if the target document and the sheet have different programming rights levels and if so it sets the content author of the target document to the content author of the sheet before rendering the sheet in the context of the target document. This seems to work: the programming level of the sheet is preserved. The only downside might be, I think, that if you print $doc.contentAuthor in the sheet you won't get the content author of the target document. I haven't tested yet though. Thanks, Marius
Denis
Thanks, Marius
You have opened the pandora box :)
Denis
Thanks, Marius
Happy coding, Anca
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 08/31/2011 11:08 AM, Marius Dumitru Florea wrote:
On Wed, Aug 31, 2011 at 11:41 AM, Anca Luca<[email protected]> wrote:
Off the top of my head:
On 08/31/2011 10:16 AM, Marius Dumitru Florea wrote:
Hi devs,
I need your feedback regarding two use cases:
(A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR
Drop permissions when rendering the sheet, right? it only seems normal to me too...
(B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR
How often did you write class/document sheets requiring programming rights? The pb is not how often, but if there's one usecase and we'd make it impossible by this approach, without having a workaround for it. I think there might be cases when you need a sheet with programming rights...
I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights.
I cannot think of usecases right now, but I would make it behave like {{include}} with context=old, because this is the way we used sheets before... (which I think means not having pr for Space2.SheetWithPR) So rendering the Space2.SheetWithPR without programming rights when the target document doesn't have programming rights is acceptable in your opinion right?
I tend to think the same as Jerome and Denis there, I can see usecases when the sheet needs PR and the document cannot have them. Also, yes, I think there might be some room for exploits there if we use the sheet rights and not the doc rights, _although_ we can consider this is the responsibility of the sheet author (e.g. if you execute stuff from the including doc, you need to make sure that the stuff that you execute is not dangerous). If we don't allow pr in the case of B, it would be interesting to see if there would be a workaround for these cases, I.e. if you need to write an app where the sheet needs programming rights but the doc cannot have them (since they are docs created by the users), do you have some other way of displaying a doc through a sheet, not using this param? So, to answer your question, I'm not that sure anymore that it's acceptable... Initially I had thought that it makes sense for this to have the same behaviour as the include macro (because that's what we use now), but actually it has nothing to do with the include macro. We used include macro for sheets because we didn't have a better way, but actually the include macro is not a sheet specific solution, it is just a generic macro to include a doc in another one, which happens to be applied for the sheets system. If this is for building a sheet specific system, we can define a new behaviour, where the rights of the sheet win. in a word, I have no idea, I am aware that there are usecases for using prog rights for B and I would like to not forbid them because we might not be able to do some things and use some API that we could before (i'm afraid that the general direction of preventing PR everywhere because bad things might happen takes us to a place where we cannot actually use them anywhere). Thanks, Anca
I suppose that when you create a sheet that requires programming rights you make sure all pages that use that sheet have also programming rights.
Thanks, Marius
Happy coding, Anca
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hello, On Wed, Aug 31, 2011 at 11:16 AM, Marius Dumitru Florea < [email protected]> wrote:
Hi devs,
I need your feedback regarding two use cases:
(A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR
Drop permissions when rendering the sheet, right?
(B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR
How often did you write class/document sheets requiring programming rights? I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights.
The only use case where I used a sheet requiring programming rights was when the users creating pages based on that sheet had programming rights (they were administrators). I see no other use case for (B) since in order for the code inside the sheet requiring programming rights to execute, the page using that sheet must be saved with programming rights. Raluca.
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Anca Luca -
Denis Gervalle -
Jerome Velociter -
Marius Dumitru Florea -
Raluca Stavro