[xwiki-devs] Introduce new tempresource action
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(). 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. <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 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. 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
Hi On 12/6/09 9: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().
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.
<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
Why not /xwiki/bin/temporary/Space/Page/SomeResource ? Its consistent with the way others URL schemes are built (for example the download action). I don't think we have a strong need to check against something else than the view right, do we? (at least in a first version). wdyt ? Jerome.
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.
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
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Mon, Dec 7, 2009 at 12:23 PM, Jerome Velociter <jerome@xwiki.com> wrote:
Hi
On 12/6/09 9: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.
Sounds nice :-)
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().
Having an action dedicated to temporary files sounds good to me. It could be useful for plenty of macros in the future (Office document displayer, formula, graphviz etc...)
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.
<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
Why not /xwiki/bin/temporary/Space/Page/SomeResource ?
Its consistent with the way others URL schemes are built (for example the download action). I don't think we have a strong need to check against something else than the view right, do we? (at least in a first version).
I agree with jerome here binding rights for this action to the view right sounds good enough to me for a first version. Guillaume
wdyt ?
Jerome.
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.
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
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
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/
Hi, On Dec 7, 2009, at 10:20 PM, Sergiu Dumitriu wrote:
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.
I agree.
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?
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.
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?
Exactly. That's why I suggested an alternative below. I was brainstorming live...
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.
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...
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
Hi Devs,
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...
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>
Is anybody working on this? I'm also in need of this functionality and want to start working on it. Please let me know if any of you (vincent?) has already done some work on it. - Asiri
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On 12/31/2009 01:06 PM, Asiri Rathnayake wrote:
Hi Devs,
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...
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>
Is anybody working on this? I'm also in need of this functionality and want to start working on it.
Me too.
Please let me know if any of you (vincent?) has already done some work on it.
- Asiri
-- Sergiu Dumitriu http://purl.org/net/sergiu/
If you wanted to do it by writing a component implementing Action instead of through struts, I have the XWikiServlet working, I can commit the patch if your interested. I just need to know what the servlet should be mapped to in web.xml /x/ ? Caleb Asiri Rathnayake wrote:
Hi,
Is anybody working on this? I'm also in need of this functionality and want
to start working on it.
Me too.
Ok you can work on it (I'm so generous). Let me know when you are finished :P
- Asiri _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Fri, Jan 1, 2010 at 3:42 PM, Caleb James DeLisle < calebdelisle@lavabit.com> wrote:
If you wanted to do it by writing a component implementing Action instead of through struts, I have the XWikiServlet working, I can commit the patch if your interested.
Yup, that would be nice. But I think this will take some time (discussions, proposals, votes etc.). - Asiri
Yes it does sound like it will be too much waiting. It's unfortunate that the old core has to be added to, but at the moment I see no way around it. Caleb Asiri Rathnayake wrote:
Hi,
On Fri, Jan 1, 2010 at 3:42 PM, Caleb James DeLisle < calebdelisle@lavabit.com> wrote:
If you wanted to do it by writing a component implementing Action instead of through struts, I have the XWikiServlet working, I can commit the patch if your interested.
Yup, that would be nice. But I think this will take some time (discussions, proposals, votes etc.).
- Asiri _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi All, Sorry about digging this up now but I need this if I'm to get started with officepreview integration.
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...
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>
One small remark: in officeimporter we need to be capable of previewing multiple attachments on the same document. And to make things worse, each attachment might be exploded into multiple artifacts (image files). So the trailing <resource name> segment of above URL might pose collision issues. There are two ways to avoid this: 1. Make sure <resource name> is unique for each image file generated (UUID). 2. Change the URL to something like below: /xwiki/bin/tmp/<space>/<page>/<module name>/path/to/resource Now, about protecting against a user simply changing <space> and <page> segments of above URL and getting access to a file to which he should not have access: We can organize the files inside working directory so that the internal path starts with something like $WORK_DIR/wiki/space/page? or even $WORK_DIR/SHA_1(wiki)/SHA_1(space)/SHA_1(page)? (in case if there needs to be some cleaning of wiki,space or page names) I'm only thinking out lound here and would like your comments on this. We really need this functionality asap. Thanks. - Asiri
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi Devs, I have implemented tempresource action and it is attached here: http://jira.xwiki.org/jira/browse/XWIKI-5227 If you are all ok with this, I can go ahead and commit (I thought it could benefit from a small review). Thanks. - Asiri
Hi, Vincent: Please don't be mad at me. I think it's a cool trick. But I don't think rendering ascii graph into bitmap will add too much information. And ordinary users will still find it hard to use. How about embedding a AJAX or flash based graphics editor? I know there are some good ones, but I don't know whether there are some open source alternatives. Here are some live demos: http://www.lucidchart.com/documents/demo http://www.drawanywhere.com/demo.aspx And the best one: http://www.gliffy.com/ which requires an account. On Mon, Dec 7, 2009 at 4:11 AM, Vincent Massol <vincent@massol.net> 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().
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.
<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
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.
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
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- -- Zhaolin Feng -- www.mapbar.com -- Currahee! We stand alone together!
Hi Zhalin, On Dec 14, 2009, at 5:21 PM, Zhaolin Feng wrote:
Hi, Vincent:
Please don't be mad at me.
:)
I think it's a cool trick. But I don't think rendering ascii graph into bitmap will add too much information.
The mail wasn't about Ditaa. It was about introducing a temresource action.
And ordinary users will still find it hard to use.
How about embedding a AJAX or flash based graphics editor? I know there are some good ones, but I don't know whether there are some open source alternatives.
Here are some live demos:
http://www.lucidchart.com/documents/demo http://www.drawanywhere.com/demo.aspx
And the best one: http://www.gliffy.com/ which requires an account.
Yes Gliffy is great. I'd love to have it. When can you start implementing the integration? :) Thanks -Vincent
On Mon, Dec 7, 2009 at 4:11 AM, Vincent Massol <vincent@massol.net> 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().
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.
<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
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.
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
Vincent: I know I can't. But I just want to know if someone else have some knowledge of open source alternatives. If so, the integration is possible then. On Tue, Dec 15, 2009 at 12:34 AM, Vincent Massol <vincent@massol.net> wrote:
Hi Zhalin,
On Dec 14, 2009, at 5:21 PM, Zhaolin Feng wrote:
Hi, Vincent:
Please don't be mad at me.
:)
I think it's a cool trick. But I don't think rendering ascii graph into bitmap will add too much information.
The mail wasn't about Ditaa. It was about introducing a temresource action.
And ordinary users will still find it hard to use.
How about embedding a AJAX or flash based graphics editor? I know there are some good ones, but I don't know whether there are some open source alternatives.
Here are some live demos:
http://www.lucidchart.com/documents/demo http://www.drawanywhere.com/demo.aspx
And the best one: http://www.gliffy.com/ which requires an account.
Yes Gliffy is great. I'd love to have it. When can you start implementing the integration? :)
Thanks -Vincent
On Mon, Dec 7, 2009 at 4:11 AM, Vincent Massol <vincent@massol.net> 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().
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.
<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
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.
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
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- -- Zhaolin Feng -- www.mapbar.com -- Currahee! We stand alone together!
On Dec 14, 2009, at 5:41 PM, Zhaolin Feng wrote:
Vincent:
I know I can't. But I just want to know if someone else have some knowledge of open source alternatives. If so, the integration is possible then.
It's also possible with non open source tools. For example we have Balsamiq integration which is great. We had a google summer of code for integration a drawing app but it didn't succeed: http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/CollaborativeBusiness... Thanks -Vincent
On Tue, Dec 15, 2009 at 12:34 AM, Vincent Massol <vincent@massol.net> wrote:
Hi Zhalin,
On Dec 14, 2009, at 5:21 PM, Zhaolin Feng wrote:
Hi, Vincent:
Please don't be mad at me.
:)
I think it's a cool trick. But I don't think rendering ascii graph into bitmap will add too much information.
The mail wasn't about Ditaa. It was about introducing a temresource action.
And ordinary users will still find it hard to use.
How about embedding a AJAX or flash based graphics editor? I know there are some good ones, but I don't know whether there are some open source alternatives.
Here are some live demos:
http://www.lucidchart.com/documents/demo http://www.drawanywhere.com/demo.aspx
And the best one: http://www.gliffy.com/ which requires an account.
Yes Gliffy is great. I'd love to have it. When can you start implementing the integration? :)
Thanks -Vincent
On Mon, Dec 7, 2009 at 4:11 AM, Vincent Massol <vincent@massol.net> 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().
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.
<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
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.
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
participants (7)
-
Asiri Rathnayake -
Caleb James DeLisle -
Guillaume Lerouge -
Jerome Velociter -
Sergiu Dumitriu -
Vincent Massol -
Zhaolin Feng