You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by "Jürgen Weber (JIRA)" <ji...@apache.org> on 2010/01/17 20:41:54 UTC
[jira] Created: (JSPWIKI-628) Load Plugin resources from classpath
Load Plugin resources from classpath
------------------------------------
Key: JSPWIKI-628
URL: https://issues.apache.org/jira/browse/JSPWIKI-628
Project: JSPWiki
Issue Type: Improvement
Affects Versions: 2.8.3
Reporter: Jürgen Weber
Some plugins require the browser to load files. E.g. the FreeMindPlugin needs the browser to load the applet's classes, or another plugin might need some flash code.
Currently the solution is to attach these files to a page which has the sole purpose of having the attachment. This is kind of awkward.
JSPWiki should have a mechanism (in JSPFilter?) which would load the file from the classpath. So for FreeMind the FreeMindPlugin.jar would additionally contain freemindbrowser.jar. The plugin would generate some markup that would make the Filter recognize that the parameter is to be loaded from classpath, e.g. <wiki:IncludeResource freemindbrowser.jar>
I guess this could be done with a PageFilter, too, but the idea is to make installing plugins easier and having to add a filters.xml would be counterproductive, so the mechanism should go into core.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JSPWIKI-628) Load Plugin resources from
classpath
Posted by "Jürgen Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802147#action_12802147 ]
Jürgen Weber commented on JSPWIKI-628:
--------------------------------------
The suggested mechanism would only make sense in core, else it would fail to make deployment easier.
To counter your security concerns, one could check, that the downloadable resource indeed is in the jar of the plugin:
URL resource = T.class.getResource("/antlr/ANTLRParser.class");
System.out.println(resource);
outputs
jar:file:/D:/eclipseworkspace/WikiExport/lib/antlr-2.7.7.jar!/antlr/ANTLRParser.class
So one would only have to check that the part before the ! would match.
> Load Plugin resources from classpath
> ------------------------------------
>
> Key: JSPWIKI-628
> URL: https://issues.apache.org/jira/browse/JSPWIKI-628
> Project: JSPWiki
> Issue Type: Improvement
> Affects Versions: 2.8.3
> Reporter: Jürgen Weber
>
> Some plugins require the browser to load files. E.g. the FreeMindPlugin needs the browser to load the applet's classes, or another plugin might need some flash code.
> Currently the solution is to attach these files to a page which has the sole purpose of having the attachment. This is kind of awkward.
> JSPWiki should have a mechanism (in JSPFilter?) which would load the file from the classpath. So for FreeMind the FreeMindPlugin.jar would additionally contain freemindbrowser.jar. The plugin would generate some markup that would make the Filter recognize that the parameter is to be loaded from classpath, e.g. <wiki:IncludeResource freemindbrowser.jar>
> I guess this could be done with a PageFilter, too, but the idea is to make installing plugins easier and having to add a filters.xml would be counterproductive, so the mechanism should go into core.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (JSPWIKI-628) Load Plugin resources from classpath
Posted by "Andrew Jaquith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Jaquith closed JSPWIKI-628.
----------------------------------
Resolution: Won't Fix
Jürgen, thanks for your comments. I understand your issue better now.
I still don't think it is wise to allow arbitrary class file downloads via a plugin. I agree that this might be useful in your particular case. I also agree that, in general, the class files in JSPWiki are not themselves sensitive (there are no secrets embedded in them).
But we can't guarantee this will always be the case, and we can't guarantee third-party JARs we bundle won't have sensitive information in them. And if improperly programmed, it might allow access to arbitrary resources inside WEB-INF. Nobody on the core team has enough time or resources to think of all the ways that a plugin like this might be abused, or of all the checks and unit tests that would need to be created to ensure its safety.
For these reasons, I don't think a general-purpose download capability for all classes in the classpath would be a good thing -- at least not in the core distro.
You are welcome, as always, to create your own plugin that does this.
> Load Plugin resources from classpath
> ------------------------------------
>
> Key: JSPWIKI-628
> URL: https://issues.apache.org/jira/browse/JSPWIKI-628
> Project: JSPWiki
> Issue Type: Improvement
> Affects Versions: 2.8.3
> Reporter: Jürgen Weber
>
> Some plugins require the browser to load files. E.g. the FreeMindPlugin needs the browser to load the applet's classes, or another plugin might need some flash code.
> Currently the solution is to attach these files to a page which has the sole purpose of having the attachment. This is kind of awkward.
> JSPWiki should have a mechanism (in JSPFilter?) which would load the file from the classpath. So for FreeMind the FreeMindPlugin.jar would additionally contain freemindbrowser.jar. The plugin would generate some markup that would make the Filter recognize that the parameter is to be loaded from classpath, e.g. <wiki:IncludeResource freemindbrowser.jar>
> I guess this could be done with a PageFilter, too, but the idea is to make installing plugins easier and having to add a filters.xml would be counterproductive, so the mechanism should go into core.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JSPWIKI-628) Load Plugin resources from
classpath
Posted by "Murray Altheim (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802096#action_12802096 ]
Murray Altheim commented on JSPWIKI-628:
----------------------------------------
Having written quite a number of plugins myself, I must agree with Andrew on this, i.e., that this should not be part of the core distribution. I have a number of plugins (such as the GroovyPlugin) that are very useful for me working locally or within an intranet environment, but completely unsuitable for use in a public, production environment.
After all the effort that has lately gone into improving security, and considering the increasing sophistication of security attacks, it would seem very counterproductive to add a new feature that potentially opens a large security hole in the code, particularly considering the wholesale damage that could be done in a wiki environment. It's hard to warrant any new features that decrease security. For this reason alone I think it prudent to develop this plugin independently, post it or a link to it on the JSPWiki site, and include appropriate warnings (as we do elsewhere) on use of the plugin on public wiki sites.
It may be very useful in secure environments but if it's part of the core distribution it becomes part of every installation, which could be problematic. Admins who want this functionality and understand the risks can easily install the plugin.
> Load Plugin resources from classpath
> ------------------------------------
>
> Key: JSPWIKI-628
> URL: https://issues.apache.org/jira/browse/JSPWIKI-628
> Project: JSPWiki
> Issue Type: Improvement
> Affects Versions: 2.8.3
> Reporter: Jürgen Weber
>
> Some plugins require the browser to load files. E.g. the FreeMindPlugin needs the browser to load the applet's classes, or another plugin might need some flash code.
> Currently the solution is to attach these files to a page which has the sole purpose of having the attachment. This is kind of awkward.
> JSPWiki should have a mechanism (in JSPFilter?) which would load the file from the classpath. So for FreeMind the FreeMindPlugin.jar would additionally contain freemindbrowser.jar. The plugin would generate some markup that would make the Filter recognize that the parameter is to be loaded from classpath, e.g. <wiki:IncludeResource freemindbrowser.jar>
> I guess this could be done with a PageFilter, too, but the idea is to make installing plugins easier and having to add a filters.xml would be counterproductive, so the mechanism should go into core.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JSPWIKI-628) Load Plugin resources from classpath
Posted by "Jürgen Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jürgen Weber reopened JSPWIKI-628:
----------------------------------
> Load Plugin resources from classpath
> ------------------------------------
>
> Key: JSPWIKI-628
> URL: https://issues.apache.org/jira/browse/JSPWIKI-628
> Project: JSPWiki
> Issue Type: Improvement
> Affects Versions: 2.8.3
> Reporter: Jürgen Weber
>
> Some plugins require the browser to load files. E.g. the FreeMindPlugin needs the browser to load the applet's classes, or another plugin might need some flash code.
> Currently the solution is to attach these files to a page which has the sole purpose of having the attachment. This is kind of awkward.
> JSPWiki should have a mechanism (in JSPFilter?) which would load the file from the classpath. So for FreeMind the FreeMindPlugin.jar would additionally contain freemindbrowser.jar. The plugin would generate some markup that would make the Filter recognize that the parameter is to be loaded from classpath, e.g. <wiki:IncludeResource freemindbrowser.jar>
> I guess this could be done with a PageFilter, too, but the idea is to make installing plugins easier and having to add a filters.xml would be counterproductive, so the mechanism should go into core.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JSPWIKI-628) Load Plugin resources from
classpath
Posted by "Jürgen Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801780#action_12801780 ]
Jürgen Weber commented on JSPWIKI-628:
--------------------------------------
> Allowing a plugin to load (and possible execute) arbitrary Java classes would be very unwise.
This is already the case. A plugin currently runs in the JSPWiki VM and can execute any Java code. The wiki admin allows this implicitly by installing the plugin.
But my request is different. Please do read my original comment. I want to make files in plugin.jars downloadable to the browser.
The plugin would finally generate a link like
/wiki/classpath/org.apache.wiki.MyApplet.class
If the file is a class, it is executed as servlet in the browser, and not in the server.
Indeed, one could download all files reachable by the server classpath. So what? There are no secrets in it, only what is in the JSPWiki download. And second, which file is downloadable from the classpath, is decided in the plugin source code and not in the plugin-usage. And plugin source code has all rights, anyway, so you have to trust the plugin author.
> Load Plugin resources from classpath
> ------------------------------------
>
> Key: JSPWIKI-628
> URL: https://issues.apache.org/jira/browse/JSPWIKI-628
> Project: JSPWiki
> Issue Type: Improvement
> Affects Versions: 2.8.3
> Reporter: Jürgen Weber
>
> Some plugins require the browser to load files. E.g. the FreeMindPlugin needs the browser to load the applet's classes, or another plugin might need some flash code.
> Currently the solution is to attach these files to a page which has the sole purpose of having the attachment. This is kind of awkward.
> JSPWiki should have a mechanism (in JSPFilter?) which would load the file from the classpath. So for FreeMind the FreeMindPlugin.jar would additionally contain freemindbrowser.jar. The plugin would generate some markup that would make the Filter recognize that the parameter is to be loaded from classpath, e.g. <wiki:IncludeResource freemindbrowser.jar>
> I guess this could be done with a PageFilter, too, but the idea is to make installing plugins easier and having to add a filters.xml would be counterproductive, so the mechanism should go into core.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JSPWIKI-628) Load Plugin resources from
classpath
Posted by "Murray Altheim (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802212#action_12802212 ]
Murray Altheim commented on JSPWIKI-628:
----------------------------------------
I hope you can understand that if one considers that the vast majority of installations are public sites, and even among those that are intranet installations where security is *less* of a problem, there's still going to be very few that opt to install this feature. So the concern of the development group is not whether deployment is easy or awkward but rather possible. For those who are capable of following directions, of copying jar files to directories and altering configuration files, so long as there is documentation and installation wouldn't require modification of and a recompile of the core code, the status quo would be that core remains less complicated and more secure. Having core code check for the existence of a specific plugin-related jar file in order to activate a custom and rarely-used feature is not very pretty. These are the kinds of hacks that create a lot of fragility in an application. That kind of functionality should be in the plugin itself, or some kind of bespoke utility that the plugin uses to manage files.
I've done some very extensive plugin development (e.g., I think over 60 so far, including several managers that themselves use a dozen or so plugins) and some have required configuration changes. But the JSPWiki 2.8.* API is significantly flexible and allows a huge amount of variability in configurations. On those rare occasions when I couldn't accomplish something, Janne was generous enough to permit several modifications. The cascading properties feature and the existing plugin manager provide everything I've needed so far.
Now, if there are changes required to core in order to make use of your plugin *possible* that would certainly be a reasonable request.
> Load Plugin resources from classpath
> ------------------------------------
>
> Key: JSPWIKI-628
> URL: https://issues.apache.org/jira/browse/JSPWIKI-628
> Project: JSPWiki
> Issue Type: Improvement
> Affects Versions: 2.8.3
> Reporter: Jürgen Weber
>
> Some plugins require the browser to load files. E.g. the FreeMindPlugin needs the browser to load the applet's classes, or another plugin might need some flash code.
> Currently the solution is to attach these files to a page which has the sole purpose of having the attachment. This is kind of awkward.
> JSPWiki should have a mechanism (in JSPFilter?) which would load the file from the classpath. So for FreeMind the FreeMindPlugin.jar would additionally contain freemindbrowser.jar. The plugin would generate some markup that would make the Filter recognize that the parameter is to be loaded from classpath, e.g. <wiki:IncludeResource freemindbrowser.jar>
> I guess this could be done with a PageFilter, too, but the idea is to make installing plugins easier and having to add a filters.xml would be counterproductive, so the mechanism should go into core.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (JSPWIKI-628) Load Plugin resources from classpath
Posted by "Andrew Jaquith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JSPWIKI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Jaquith closed JSPWIKI-628.
----------------------------------
Resolution: Won't Fix
As described, this enhancement request represents a significant security risk. Allowing a plugin to load (and possible execute) arbitrary Java classes would be very unwise. This risk would be compounded by the fact that few servers run JSPWiki with a security manager, meaning that a malicious party might have the run over the entire server.
That said, if a website operator wishes to change the JSPs to allow particular applets to load, that would be fine. The can do that today. But having a general purpose classloading capability, able to be invoked by anyone, is a recipe for trouble.
But perhaps I misunderstood your request? If I misunderstood, please re-open and re-state... and make sure you document any security considerations that would be part of this enhancement.
> Load Plugin resources from classpath
> ------------------------------------
>
> Key: JSPWIKI-628
> URL: https://issues.apache.org/jira/browse/JSPWIKI-628
> Project: JSPWiki
> Issue Type: Improvement
> Affects Versions: 2.8.3
> Reporter: Jürgen Weber
>
> Some plugins require the browser to load files. E.g. the FreeMindPlugin needs the browser to load the applet's classes, or another plugin might need some flash code.
> Currently the solution is to attach these files to a page which has the sole purpose of having the attachment. This is kind of awkward.
> JSPWiki should have a mechanism (in JSPFilter?) which would load the file from the classpath. So for FreeMind the FreeMindPlugin.jar would additionally contain freemindbrowser.jar. The plugin would generate some markup that would make the Filter recognize that the parameter is to be loaded from classpath, e.g. <wiki:IncludeResource freemindbrowser.jar>
> I guess this could be done with a PageFilter, too, but the idea is to make installing plugins easier and having to add a filters.xml would be counterproductive, so the mechanism should go into core.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.