Stephan Hesmer wrote:
> There is possibly a new bug in Jetspeed, due to the changes to EngineContext
> and JetspeedServlet.
>
> The new getResource function in EngineContext returns an url to a resource
> on the server, which is normally local. For example:
> It returns "file:D:\jakarta-tomcat\webapps\ROOT/content/psml/default.psml"
> for "/content/psml/default.psml"
>
> This causes several problems:
> * the RSS portlet is not running anymore (in my case the Jetspeed portlet),
> and
> * the url is not considered as local from Jetspeed (Jetspeed it looking for
> "file://")
>
Yes. Yesterday we noticed this bug and we are reserching it.
>
> While changing and testing it on my PC, I discovered several code pieces,
> which do not make sense or I simply do not understand:
> * PortletFactory
> //make sure that no one tries to instantiate a portlet with a file
> URL
> if ( pc.getURL() != null && pc.getURL().indexOf( "file://" ) == 0 )
> {
> String message = "Local URLs not served through HTTP to prevent
> security holes: " + pc.getURL();
> Log.error( message );
> throw new PortletException( message );
> }
> ok, before modifying EngineContext a local URL was represented by
> "http://localhost:port/..." . But now, it is something like "file:D:/....".
> So, do we have luck that we are asking here for "file://" ? Surely, we can
> not rely on that information, because other servers than Tomcat could return
> "file://".
In our copy, only Jetspeed.rss gets problems. The "remote" ones are handled
allright. I will look at differences WRT cvs to check for changes.
>
> On the other side, we will get a problem when fixing this code... nearly
> every portlet is rejected and therefore not displayed
>
> * JetspeedDiskCache
> //attempt to see if the user didn't specify a URL if they didn't
> then
> //assume it is localhost with the servlet port
> if ( DiskCacheUtils.isLocal( url ) &&
> url.indexOf("file://") == -1 ) {
> Why do we ask here for isLocal and forbid "file://" ? Someone who knows this
> code better than me?
>
> * DiskCacheUtils
> In this file you can find the isLocal function, which asks for "file://"....
> do I have to say anymore?
>
> There are some other files which are affected, but they are quite simple.
>
> I think, that Jetspeed needs to recognize this type of URL (file:D:/...) as
> local, and therefore we have to change the files I mentioned above. Does
> anybody know who wrote or modified the files or who is working on the
> isLocal stuff?
I am, thanks. We tried to deprecate file:/ URLs some time ago because they
caused lots of problems dealing with the different jdk versions/servlet
containers.
To my understanding, file:D: is not a legal url, neither file:/D: is. A file url
is:
file://server/path. When it is local, it is file:///path.
An absolute path under windows is: /D:/... (See jdk documentation)
So, a legal windows file url would be file:///D:/...
This fact has made lots of problems around, hence why we tried to forbid file
urls from the system. This way, you can use http: URLs, and server the documents
from anywhere in the internet, for instance having a farm of machines take
"local" content from a content server.
I am investigating this issue and will report when I find something.
We are also also breaking Cocoon Portlets, so that if you recompile any Cocoon
portlet, it will not work anymore.
>
>
> Thanks,
> Stephan
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
