[xwiki-devs] [proposal] Add an API function to drop permissions for the remainder of the document rendering.
10 Aug
2011
10 Aug
'11
12:22 p.m.
Right now we have dropPermissions which makes a specific guarantee, there will not be any
programming
right for the duration of the request cycle.
Sometimes a user might want to drop permissions for the duration of the document
rendering.
This would mean {{include}} macros, $doc.getRenderedContent() would allow permissions to
be gained back
while the included document was being rendered and after the content of that document is
finished
rendering, the permissions would be returned.
I think it would do more harm than good to break the promise that dropPermissions() makes
so I propose
adding $doc.dropPermissions() to do this.
I think $doc.dropPermissions() vs. $context.dropPermissions() is intuitive and easily
explained but if
anyone has another suggestion for a name, I'd be glad to hear it.
WDYT?
Caleb
10 Aug
10 Aug
2:35 p.m.
On Wed, Aug 10, 2011 at 12:22 PM, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
Right now we have dropPermissions which makes a
specific guarantee, there will not be any programming
right for the duration of the request cycle.
Sometimes a user might want to drop permissions for the duration of the document
rendering.
This would mean {{include}} macros, $doc.getRenderedContent() would allow permissions to
be gained back
while the included document was being rendered and after the content of that document is
finished
rendering, the permissions would be returned.
I think it would do more harm than good to break the promise that dropPermissions() makes
so I propose
adding $doc.dropPermissions() to do this.
I think $doc.dropPermissions() vs. $context.dropPermissions() is intuitive and easily
explained but if
anyone has another suggestion for a name, I'd be glad to hear it.
Sounds good.
WDYT?
+1
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
11 Aug
11 Aug
11:07 a.m.
On Wed, Aug 10, 2011 at 14:35, Thomas Mortagne <thomas.mortagne(a)xwiki.com>wrote;wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
On Wed, Aug 10, 2011 at 12:22 PM, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
If you means that you prefer a $doc.dropPermissions() to a
$context.getBackPermission(), I am +1.
Denis
Right now we have dropPermissions which makes a
specific guarantee, there
will not be any programming
right for the duration of the request cycle.
Sometimes a user might want to drop permissions for the duration of the
document
rendering.
This would mean {{include}} macros,
$doc.getRenderedContent() would allow
permissions to be gained back
while the included document was being rendered
and after the content of
that document is finished
rendering, the permissions would be returned.
I think it would do more harm than good to break the promise that
dropPermissions() makes so I propose
adding $doc.dropPermissions() to do this.
I think $doc.dropPermissions() vs. $context.dropPermissions() is
intuitive and
easily explained but if
anyone has another suggestion for a name, I'd
be glad to hear it.
Sounds good.
WDYT?
+1
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:27 p.m.
On 08/11/2011 05:07 AM, Denis Gervalle wrote:
On Wed, Aug 10, 2011 at 14:35, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
Yes, I would like to avoid changing the guarantee made by $xcontext.dropPermissions()
and a getBackPermissions() would invalidate it.
Caleb
On Wed, Aug 10, 2011 at 12:22 PM, Caleb James
DeLisle
<calebdelisle(a)lavabit.com> wrote:
If you means that you prefer a $doc.dropPermissions() to a
$context.getBackPermission(), I am +1. Right now we have dropPermissions which makes a
specific guarantee, there
will not be any programming
right for the duration of the request cycle.
Sometimes a user might want to drop permissions for the duration of the
document
rendering.
This would mean {{include}} macros,
$doc.getRenderedContent() would allow
permissions to be gained back
while the included document was being rendered
and after the content of
that document is finished
rendering, the permissions would be returned.
I think it would do more harm than good to break the promise that
dropPermissions() makes so I propose
adding $doc.dropPermissions() to do this.
Denis
I think $doc.dropPermissions() vs. $context.dropPermissions() is
intuitive and
easily explained but if
anyone has another suggestion for a name, I'd
be glad to hear it.
Sounds good.
WDYT?
+1
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
13 Aug
13 Aug
8:23 a.m.
On 08/10/2011 06:22 AM, Caleb James DeLisle wrote:
Right now we have dropPermissions which makes a
specific guarantee, there will not be any programming
right for the duration of the request cycle.
Sometimes a user might want to drop permissions for the duration of the document
rendering.
This would mean {{include}} macros, $doc.getRenderedContent() would allow permissions to
be gained back
while the included document was being rendered and after the content of that document is
finished
rendering, the permissions would be returned.
I think it would do more harm than good to break the promise that dropPermissions() makes
so I propose
adding $doc.dropPermissions() to do this.
I think $doc.dropPermissions() vs. $context.dropPermissions() is intuitive and easily
explained but if
anyone has another suggestion for a name, I'd be glad to hear it.
Can you give me a better example, when would doc.dropPermission be
needed and context.dropPermission is too much? How would you get back
rights? And how do you prevent the supposedly sandboxed code from using
the same mechanism to get back the rights?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
2:48 p.m.
The new dropPermissions could be used wherever the old dropPermissions is being used
currently.
It would be possible to add it to the top of globalvars.vm and it would drop permissions
except that
they could be regained once the document content began being rendered and would of course
go away again
when the document content was finished being rendered.
NOTE: This hinges on http://jira.xwiki.org/jira/browse/XWIKI-4274 being fixed.
I am a bit reserved about the name though since it drops for this "rendering
cycle" so:
{{groovy}}
println('Hello World!');
if (xcontext.get('runOnce')) {
xcontext.set('runOnce', true);
doc.dropPermissions();
doc.getRenderedContent(doc.getContent());
}
{{/groovy}}
would output:
Hello World!
Hello World!
Which means that doc.dropPermissions() is not entirely accurate since the same document
can get
permissions in the same request cycle. It should really be
renderingCycle.dropPermissions() but that
would make no sense to anyone at all. If anyone can think of a better name I'd be
happy to hear it.
Caleb
On 08/13/2011 02:23 AM, Sergiu Dumitriu wrote:
On 08/10/2011 06:22 AM, Caleb James DeLisle wrote:
Right now we have dropPermissions which makes a
specific guarantee, there will not be any programming
right for the duration of the request cycle.
Sometimes a user might want to drop permissions for the duration of the document
rendering.
This would mean {{include}} macros, $doc.getRenderedContent() would allow permissions to
be gained back
while the included document was being rendered and after the content of that document is
finished
rendering, the permissions would be returned.
I think it would do more harm than good to break the promise that dropPermissions() makes
so I propose
adding $doc.dropPermissions() to do this.
I think $doc.dropPermissions() vs. $context.dropPermissions() is intuitive and easily
explained but if
anyone has another suggestion for a name, I'd be glad to hear it.
Can you give me a better example, when would doc.dropPermission be
needed and context.dropPermission is too much? How would you get back
rights? And how do you prevent the supposedly sandboxed code from using
the same mechanism to get back the rights?
3:02 p.m.
On 08/13/2011 08:48 AM, Caleb James DeLisle wrote:
The new dropPermissions could be used wherever the old
dropPermissions is being used currently.
It would be possible to add it to the top of globalvars.vm and it would drop permissions
except that
they could be regained once the document content began being rendered and would of course
go away again
when the document content was finished being rendered.
NOTE: This hinges on http://jira.xwiki.org/jira/browse/XWIKI-4274 being fixed.
Correction: Use of getRenderedContent() hinges on XWiki-4274 being fixed. {{include}},
#includeTopic and getRenderedContent(doc.getContent()) would work anyway.
Caleb
I am a bit reserved about the name though since it drops for this "rendering
cycle" so:
{{groovy}}
println('Hello World!');
if (xcontext.get('runOnce')) {
xcontext.set('runOnce', true);
doc.dropPermissions();
doc.getRenderedContent(doc.getContent());
}
{{/groovy}}
would output:
Hello World!
Hello World!
Which means that doc.dropPermissions() is not entirely accurate since the same document
can get
permissions in the same request cycle. It should really be
renderingCycle.dropPermissions() but that
would make no sense to anyone at all. If anyone can think of a better name I'd be
happy to hear it.
Caleb
On 08/13/2011 02:23 AM, Sergiu Dumitriu wrote:
On 08/10/2011 06:22 AM, Caleb James DeLisle
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Right now we have dropPermissions which makes a
specific guarantee, there will not be any programming
right for the duration of the request cycle.
Sometimes a user might want to drop permissions for the duration of the document
rendering.
This would mean {{include}} macros, $doc.getRenderedContent() would allow permissions to
be gained back
while the included document was being rendered and after the content of that document is
finished
rendering, the permissions would be returned.
I think it would do more harm than good to break the promise that dropPermissions() makes
so I propose
adding $doc.dropPermissions() to do this.
I think $doc.dropPermissions() vs. $context.dropPermissions() is intuitive and easily
explained but if
anyone has another suggestion for a name, I'd be glad to hear it.
Can you give me a better example, when would doc.dropPermission be
needed and context.dropPermission is too much? How would you get back
rights? And how do you prevent the supposedly sandboxed code from using
the same mechanism to get back the rights?
10:25 a.m.
New subject: [xwiki-devs] [proposal] Add an API function to drop permissions for the remainder of the document rendering.
Hi Caleb,
On Aug 10, 2011, at 12:22 PM, Caleb James DeLisle wrote:
Right now we have dropPermissions which makes a
specific guarantee, there will not be any programming
right for the duration of the request cycle.
Sometimes a user might want to drop permissions for the duration of the document
rendering.
This would mean {{include}} macros, $doc.getRenderedContent() would allow permissions to
be gained back
while the included document was being rendered and after the content of that document is
finished
rendering, the permissions would be returned.
I think it would do more harm than good to break the promise that dropPermissions() makes
so I propose
adding $doc.dropPermissions() to do this.
I think $doc.dropPermissions() vs. $context.dropPermissions() is intuitive and easily
explained but if
anyone has another suggestion for a name, I'd be glad to hear it.
WDYT?
I need some more information before giving an opinion.
Same as Sergiu I'd like some explanations as to where this would be used. Does it mean
all page content writers will need to manually call $doc.dropPermissions() whenever they
want to make their document "secure"? That seems very cumbersome and we can be
sure people won't do that.
So what use cases does this solve?
Thanks
-Vincent
Caleb
4879
days inactive
4882
days old
7 comments
5 participants
participants (5)
-
Caleb James DeLisle -
Denis Gervalle -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol