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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
