7 Dec
2009
7 Dec
'09
10:20 p.m.
On 12/06/2009 09:11 PM, Vincent Massol wrote:
Hi,
Part I
=====
I've started implementing a Ditaa Macro over the weekend
(http://ditaa.sourceforge.net/
) but we need an Action to return the Ditaa-generated image file.
For the chart macro we're using the charting action but I think we can
make this generic and instead introduce a tmp (or temp or tmpresource
or ...) action instead that would return any resource located in the
xwiki temporary directory.
For ex:
/xwiki/bin/tmp/SomeResource
would return SomeResource found in
container.getApplicationContext().getTemporaryDirectory().
Currently, most plugins that generate temporary resources don't create
them directly in the workdir, but in a subdirectory (true for chart,
svg, image, graphviz and maybe others), which reduces the risk of
collisions. I'd rather keep this functionality.
Anyway, +1 for having a common action for all generated images. This
will also reduce the need to change the rights class and the struts
config for each new plugin.
Part II
=====
The only thing to be careful about is to not be able to read what's
for another user and for which you don't have access to see it. For
example an image generated by the chart macro for a page for which the
user doesn't have view rights. This can be partially solved by
ensuring that file names include a generated token. However the pb is
that this token cannot be unique since, for ex, generated image need
to be shared to anyone having the rights to view a page.
For the moment, all such resources are generated for being displayed
inside a document, in normal view mode. Thus, I think it's enough to
check if the user has view rights on the document for which the image is
generated. Do you have any other (real) usecase in mind?
But another important issue to keep in mind is cache settings. For good
performance we should allow clients to cache the image, while preventing
other users from accessing a cached resource. Any ideas?
First, we could prevent caching on proxies. This doesn't fix the
following scenario: client logs in, views a resource, then logs out,
leaving the image in the cache.
Second, we could use somewhat short cache settings, like 10 minutes.
<brainstomring mode>
A solution I see would be to include the "rights" to check + the full
page name in the URL, in addition to the resource. For example:
/xwiki/bin/tmp/view/wiki:Space.Page/SomeResource
What prevents a user from changing the URL to use a different page name?
In other words, the owner page should not be present just in the URL,
but somehow should be connected to the resource on the server.
One idea would be to hash the page + id and store the resource using
this hash as its name. Problem: hash collisions.
Another idea would be to use a cleaned-up version of the page + id as
the resource name, but we must be careful not to let users generate
colliding resource names (for example wiki:Spa.cePage would collide with
wiki:Space.Page if the cleanup process means just removing special chars).
Or we could combine the two, for more security.
A more generic solution would be to add a notion of
Check Handler,
i.e. code that would perform the check. For example in the previous
solution it's not possible to check for 2 permissions, nor any complex
scheme. This would mean something like:
/xwiki/bin/tmp/<check handler name>/<resource name>?<check params>
Ex: /xwiki/bin/tmp/simple/SomeResource?
checkPermission="view"&checkDocument="wiki:Space.Page"
Implementation: A component with a role hint of "simple" would be
looked-up and the check logic delegated to it.
See above, I don't think this complexity is really needed.
However someone could use a some check for a resource
that wasn't
meant to be used for that resource.
Thus the check and its params should probably instead be included in
the resource name with some algorithm instead. Thus the solution maybe
to have a high level API to create a resource name and that API would
take a Check Handler hint + some arbitrary params and that API would
generate a resource name with these added. For ex something like::
"SomeResource-simple-view-wiki:Space.Page" (or any other format).
Another solution would be to follow a completely different direction
and for example to introduce a new XDOM representation for a TMP-
image, i.e. in addition to URLImage and DocumentImage, to add a
TemporaryImage implementation.
</brainstomring mode>
WDYT about these 2 ideas and especially about Part I since I would
need that sooner rather than later to implement the Ditaa macro, and
Part II is already a problem today.
Thanks
-Vincent
How about this kind of URL?
/xwiki/bin/tempresource/Space/Document/plugin/Sjqh73sjq.png
where plugin is the name of the plugin/component that generated the
image, like svg, chart, graphviz...
--
Sergiu Dumitriu
http://purl.org/net/sergiu/