Re: Possible bugs with isLocal and file://

2000-11-21 Thread Raphael Luta 

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"


Some bugs are corrected in the upcoming EngineContext service, but I think 
most of your issues will stay...
 
 This causes several problems:
 * the RSS portlet is not running anymore (in my case the Jetspeed portlet),
 and

The Jetspeed portlet is not RSS, it's jetspeed content. This works on my
machine so I believe this is already fixed in the EngineContext service.

 * the url is not considered as local from Jetspeed (Jetspeed it looking for
 "file://")

 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://".
 On the other side, we will get a problem when fixing this code... nearly
 every portlet is rejected and therefore not displayed


IMO, we should accept any URL in the PortletFactory and not filter out 'file:'
URLs.
Why ? because every URL the PortletFactory sees is "trusted" since it
can only be registered by the administrator or the feed daemon, users never
specify themselves their URLs.

I think it's safe to always trust the administrator configured file since if 
someone unauthorized can modify this file, it's most likely he can modify the 
system in other ways that would create unsecured access to local files.
However the Feed Daemon should filter which URLs it accepts to prevent bogus
feeds from creating security issues.


 * 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?


Nope. I've tried to understand to JetspeedDiskCache system when working on 
the URLManager and pretty quickly became very confused about the way it works.
Santiago seems to have got it hawever since I saw a lot of patches done by 
him in these files. 
I'm just waiting for his clean-up of this component...
 
 
 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?
 

+1 for the change.
I think Santiago or Kevin are the one who can help you on this subject.

--
Raphaël Luta - [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]

Re: Possible bugs with isLocal and file://

2000-11-21 Thread Santiago Gala 



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]

Re: Possible bugs with isLocal and file://

2000-11-21 Thread Stephan Hesmer 


 - Original Message -
 From: "Raphael Luta" [EMAIL PROTECTED]
 To: "JetSpeed" [EMAIL PROTECTED]
 Sent: Tuesday, November 21, 2000 12:13 PM
 Subject: Re: Possible bugs with isLocal and "file://"


 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"
 

 Some bugs are corrected in the upcoming EngineContext service, but I think
 most of your issues will stay...

  This causes several problems:
  * the RSS portlet is not running anymore (in my case the Jetspeed
portlet),
  and

 The Jetspeed portlet is not RSS, it's jetspeed content. This works on my
 machine so I believe this is already fixed in the EngineContext service.

I meant the "Jetspeed" portlet, which is based on the RSSPortlet. The
JetspeedContent is also working on my machine. Did I miss something here?

portlet-entry type="abstract" name="RSS"

classnameorg.apache.jetspeed.portal.portlets.RSSPortlet/classname
parameter name="itemDisplayed" value="10" type="int"/
parameter name="stylesheet" value="/content/xsl/rss.xsl"/
/portlet-entry

portlet-entry type="instance" name="JetspeedContent"

classnameorg.apache.jetspeed.portal.portlets.JetspeedContent/classname
parameter name="provider-name" value="jetspeed"/
/portlet-entry

portlet-entry type="ref" parent="RSS" name="Jetspeed"

url/content/xml/rss/Jetspeed.rss/url

/portlet-entry


  * the url is not considered as local from Jetspeed (Jetspeed it looking
for
  "file://")
 
  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://".
  On the other side, we will get a problem when fixing this code... nearly
  every portlet is rejected and therefore not displayed
 

 IMO, we should accept any URL in the PortletFactory and not filter out
'file:'
 URLs.
 Why ? because every URL the PortletFactory sees is "trusted" since it
 can only be registered by the administrator or the feed daemon, users
never
 specify themselves their URLs.

 I think it's safe to always trust the administrator configured file since
if
 someone unauthorized can modify this file, it's most likely he can modify
the
 system in other ways that would create unsecured access to local files.
 However the Feed Daemon should filter which URLs it accepts to prevent
bogus
 feeds from creating security issues.


  * 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?
 

 Nope. I've tried to understand to JetspeedDiskCache system when working on
 the URLManager and pretty quickly became very confused about the way it
works.
 Santiago seems to have got it hawever since I saw a lot of patches done by
 him in these files.
 I'm just waiting for his clean-up of this component...

 
  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?
 

 +1 for the change.
 I think Santiago or Kevin are the one who can help you on this subject.

 --
 Raphaël Luta - [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]

Re: Possible bugs with isLocal and file://

2000-11-21 Thread Santiago Gala 



Raphael Luta wrote:

 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"
 

 Some bugs are corrected in the upcoming EngineContext service, but I think
 most of your issues will stay...

  This causes several problems:
  * the RSS portlet is not running anymore (in my case the Jetspeed portlet),
  and

 The Jetspeed portlet is not RSS, it's jetspeed content. This works on my
 machine so I believe this is already fixed in the EngineContext service.

There is a jetspeed content and a Jetspeed.rss, which ceased working recently.



  * the url is not considered as local from Jetspeed (Jetspeed it looking for
  "file://")
 
  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://".
  On the other side, we will get a problem when fixing this code... nearly
  every portlet is rejected and therefore not displayed
 

 IMO, we should accept any URL in the PortletFactory and not filter out 'file:'
 URLs.
 Why ? because every URL the PortletFactory sees is "trusted" since it
 can only be registered by the administrator or the feed daemon, users never
 specify themselves their URLs.

 I think it's safe to always trust the administrator configured file since if
 someone unauthorized can modify this file, it's most likely he can modify the
 system in other ways that would create unsecured access to local files.
 However the Feed Daemon should filter which URLs it accepts to prevent bogus
 feeds from creating security issues.


The reason why file urls where filtered is because there was a problem WRT
treatment of file: urls in different OSs/jdks and also because they are not very
much network ready for escalability reasons.

In addition there were implementation problems where the "local" resource file url
in the cache was taken for a new cache entry and cached again...

I am looking into this, I hope I will clean it fast.


  * 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?
 

 Nope. I've tried to understand to JetspeedDiskCache system when working on
 the URLManager and pretty quickly became very confused about the way it works.
 Santiago seems to have got it hawever since I saw a lot of patches done by
 him in these files.
 I'm just waiting for his clean-up of this component...

 
  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?
 

 +1 for the change.
 I think Santiago or Kevin are the one who can help you on this subject.

 --
 Raphaël Luta - [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]



--
--
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]

Re: Possible bugs with isLocal and file://

2000-11-21 Thread Stephan Hesmer 


- Original Message -
From: "Santiago Gala" [EMAIL PROTECTED]
To: "JetSpeed" [EMAIL PROTECTED]
Sent: Tuesday, November 21, 2000 12:17 PM
Subject: Re: Possible bugs with isLocal and "file://"




 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:/...

I played a little with urls myself. If you create an URL like file:///D:/...
with the class URL, it will be truncated to file:/D:/... . Some other
problems occured, if you are using file://D:/.. - this is accepted by the
URL class, but will break Jetspeed later.

 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.

Perhaps this is interesting for you:
On WebSphere the function getResource returns NOT "file:" but "classloader:"
!!!
Michael, who discovered a similar error, and I are working on it, to get a
fix.
If we have a good fix, we will post it.

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]

Re: Possible bugs with isLocal and file://

2000-11-21 Thread Raphael Luta 

Stephan Hesmer wrote:
 
  - Original Message -
  From: "Raphael Luta" [EMAIL PROTECTED]
  To: "JetSpeed" [EMAIL PROTECTED]
  Sent: Tuesday, November 21, 2000 12:13 PM
  Subject: Re: Possible bugs with isLocal and "file://"
 
 
  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"
  
 
  Some bugs are corrected in the upcoming EngineContext service, but I think
  most of your issues will stay...
 
   This causes several problems:
   * the RSS portlet is not running anymore (in my case the Jetspeed
 portlet),
   and
 
  The Jetspeed portlet is not RSS, it's jetspeed content. This works on my
  machine so I believe this is already fixed in the EngineContext service.
 
 I meant the "Jetspeed" portlet, which is based on the RSSPortlet. The
 JetspeedContent is also working on my machine. Did I miss something here?
 
 portlet-entry type="abstract" name="RSS"
 
 classnameorg.apache.jetspeed.portal.portlets.RSSPortlet/classname
 parameter name="itemDisplayed" value="10" type="int"/
 parameter name="stylesheet" value="/content/xsl/rss.xsl"/
 /portlet-entry
 
 portlet-entry type="instance" name="JetspeedContent"
 
 classnameorg.apache.jetspeed.portal.portlets.JetspeedContent/classname
 parameter name="provider-name" value="jetspeed"/
 /portlet-entry
 
 portlet-entry type="ref" parent="RSS" name="Jetspeed"
 
 url/content/xml/rss/Jetspeed.rss/url
 
 /portlet-entry
 

Sorry, I mixed the 2 portlets. If I understand correctly what you're saying it's
that every use of URI elements whithin the url tag of the jetspeed-config is
courrently broken by the use of getResource() because the implementation dependant
URL (file, classloader, whatever...) returned by the servlet runner is not accepted 
by the cache system and portlet factory. Any other uses of local URI such as the 
stylesheet parameter of the JetspeedContent works. 
Is that a correct description of the problem ?

--
Raphaël Luta - [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]

Re: Possible bugs with isLocal and file://

2000-11-21 Thread Raphael Luta 

Santiago Gala wrote:
 
 The reason why file urls where filtered is because there was a problem WRT
 treatment of file: urls in different OSs/jdks and also because they are not very
 much network ready for escalability reasons.
 

Can you describe the issue some more, I'm not sure I understand what the 
problem is ?

 In addition there were implementation problems where the "local" resource file url
 in the cache was taken for a new cache entry and cached again...


Ughh... That means there are redundant cache calls. I think we should really try 
to define an URL request mechanism independantly of the existing infrastructure and
try to move the current code to the new model.

 I am looking into this, I hope I will clean it fast.
 

:)

--
Raphaël Luta - [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]

Re: Possible bugs with isLocal and file://

2000-11-21 Thread Santiago Gala 



Stephan Hesmer wrote:

 - Original Message -
 From: "Santiago Gala" [EMAIL PROTECTED]
 To: "JetSpeed" [EMAIL PROTECTED]
 Sent: Tuesday, November 21, 2000 12:17 PM
 Subject: Re: Possible bugs with isLocal and "file://"

 
 
  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:/...

 I played a little with urls myself. If you create an URL like file:///D:/...
 with the class URL, it will be truncated to file:/D:/... . Some other
 problems occured, if you are using file://D:/.. - this is accepted by the
 URL class, but will break Jetspeed later.


The first case depends on the jdk version, I think it is a bug in jdk1.3

The second would be interpreted as whatever file in server D:, whi is nonsense,
and gives errors like "unable to find host 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.

 Perhaps this is interesting for you:
 On WebSphere the function getResource returns NOT "file:" but "classloader:"
 !!!

I think classloader uses the classloader ot the class to get resources,
following the CLASSPATH. This allows for resources to be stored in jar files,
and be managed by applications, or similarly, executed from a "sealed" WAR file.
It will not do for external or writable resources, since they are out of our
environment, or else we cannotwrite to them.

In the servl

Re: Possible bugs with isLocal and file://

2000-11-21 Thread Stephan Hesmer 


 - Original Message -
 From: "Raphael Luta" [EMAIL PROTECTED]
 To: "JetSpeed" [EMAIL PROTECTED]
 Sent: Tuesday, November 21, 2000 1:06 PM
 Subject: Re: Possible bugs with isLocal and "file://"


 Stephan Hesmer wrote:
 
   - Original Message -
   From: "Raphael Luta" [EMAIL PROTECTED]
   To: "JetSpeed" [EMAIL PROTECTED]
   Sent: Tuesday, November 21, 2000 12:13 PM
   Subject: Re: Possible bugs with isLocal and "file://"
  
  
   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"
   
  
   Some bugs are corrected in the upcoming EngineContext service, but I
think
   most of your issues will stay...
  
This causes several problems:
* the RSS portlet is not running anymore (in my case the Jetspeed
  portlet),
and
  
   The Jetspeed portlet is not RSS, it's jetspeed content. This works on
my
   machine so I believe this is already fixed in the EngineContext
service.
 
  I meant the "Jetspeed" portlet, which is based on the RSSPortlet. The
  JetspeedContent is also working on my machine. Did I miss something
here?
 
  portlet-entry type="abstract" name="RSS"
 
  classnameorg.apache.jetspeed.portal.portlets.RSSPortlet/classname
  parameter name="itemDisplayed" value="10" type="int"/
  parameter name="stylesheet" value="/content/xsl/rss.xsl"/
  /portlet-entry
 
  portlet-entry type="instance" name="JetspeedContent"
 
 
classnameorg.apache.jetspeed.portal.portlets.JetspeedContent/classname
  parameter name="provider-name" value="jetspeed"/
  /portlet-entry
 
  portlet-entry type="ref" parent="RSS" name="Jetspeed"
 
  url/content/xml/rss/Jetspeed.rss/url
 
  /portlet-entry
 

 Sorry, I mixed the 2 portlets. If I understand correctly what you're
saying it's
 that every use of URI elements whithin the url tag of the
jetspeed-config is
 courrently broken by the use of getResource() because the implementation
dependant
 URL (file, classloader, whatever...) returned by the servlet runner is not
accepted
 by the cache system and portlet factory. Any other uses of local URI such
as the
 stylesheet parameter of the JetspeedContent works.
 Is that a correct description of the problem ?

Yes, it is mainly a caching problem, but in some files the url is test for
"file://", which is also incorrect (i.e. PortletFactory).

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]