8 Dec
2009
8 Dec
'09
8:58 a.m.
Hi,
On Dec 7, 2009, at 10:20 PM, Sergiu Dumitriu wrote:
Exactly. That's why I suggested an alternative below. I was
brainstorming live...
On 12/06/2009 09:11 PM, Vincent Massol wrote:
I agree.
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.
Even for view I was thinking that maybe the code could need to check
for 2 rights in some cases. But I agree let's start simple for now.
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?
You mean if several people use the same computer?
I don't think we can cache if we really want to be safe. Or the image
would need to be locally encrypted and decrypted with a key but that
sounds overkill.
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.
Yes these are intermediary solutions but they mean it's possible for
someone to view an image he doesn't have the right to view.
<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.
Yep, hence the other proposal below.
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.
Sounds good to me for a first version.
I'd suggest instead to use the shorter "tmp" to make the URL smaller
and be aligned with other action names:
/xwiki/bin/tmp/<space>/<page>/<module name>/<resource name>
Thanks
-Vincent
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...