On Wed, Aug 31, 2011 at 14:56, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
On Wed, Aug 31, 2011 at 2:39 PM, Denis Gervalle
<dgl(a)softec.lu> wrote:
On Wed, Aug 31, 2011 at 11:08, Marius Dumitru
Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
> On Wed, Aug 31, 2011 at 11:41 AM, Anca Luca <lucaa(a)xwiki.com> 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
> 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
_______________________________________________
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