Bug in PortletConfig.java when using JDK SOCKS support or virtualhosting

[Michael D Harris/Raleigh/IBM]

I think I've found a bug in PortletConfig.java.  When relative URLs are
used in the <portlet-entry> elements of jetspeed-config.jcfg,
PortletConfig.setURL() detects that there is no server name in the URL and
"politely" adds 127.0.0.1 as the server name.  It should be adding the real
server name instead.  Take this example <portlet-entry> from
jetspeed-config.jcfg:

   <portlet-entry type="instance" name="Weather">
      <url>/xml/weather.xml</url>
      <classname>org.apache.jetspeed.portal.portlets.XSLPortlet</classname>
      <parameter name="stylesheet" value="/xsl/weather.xsl"/>
      <meta-info>
         <title>Weather</title>
         <description>Current Weather Conditions</description>
      </meta-info>
   </portlet-entry>

PortletConfig.setURL() will convert:

     /xml/weather.xml

to

   http://127.0.0.1/xml/weather.xml

This converted URL can be troublesome when using firewalls and in certain
cases, will prevent the correct content from being served when virtual
hosting is used.

First, I'll cover the firewall case.  There is a known deficiency in the
JDK with its SOCKS support.  There is no way to specify that certain URLs
(in particular "localhost" or "127.0.0.1") should be connected to directly
instead of going through the SOCKS server.  This means that if you use the
JDK's SOCKS support your firewall must be configured to properly handle
requests for 127.0.0.1.  (I'm still researching the SOCKS specification to
see if it is even valid to try to connect to "127.0.0.1" through the server
or not.)  The firewall that I use will not allow you to connect to
127.0.0.1 through it.  So any access to local content specified with a
relative URL fails.

Workarounds for this problem are to use fully-qualified URLs or socksified
TCP stacks (a better solution anyway). This problem alone isn't necessarily
enough to warrant a patch... but the next one is a bit more tricky... hang
on... it's about to get a little confusing.

If you are using Jetspeed in a virtual host configuration where multiple
instances of Jetspeed are running separate portals, you may get the wrong
content when 127.0.0.1 is used.  Imagine a server with a virtual host
configuration.  This server serves up www.salesdivision.com (which is the
default and therefore 127.0.0.1) and www.manufacturingdivision.com.
Further suppose that you want to keep the two portal's configurations
similar and choose to provide XML content to a portlet in both portals via
an XML file on the server which can be reached at /xml/weather.xml.  There
are two different copies of weather.xml on the server's disk.  One off of
the sales division web root and another off of the manufacturing division
web root.  The two different files are accessible via
http://www.salesdivision.com/xml/weather.xml and
http://www.manufacturingdivision.com/xml/weather.xml.

When a user comes to the portal via http://www.salesdivision.com, the
PortletConfig class happily loads http://127.0.0.1/xml/weather.xml (which
is the same as http://www.salesdivision.com/xml/weather.xml) and the
correct data is fed through the XSL stylesheet.

However, when a user comes to the portal via
http://www.manufacturingdivision.com, the PortletConfig class loads the XML
content via http://127.0.0.1/xml/weather.xml (which is the same as
http://www.salesdivision.com/xml/weather.xml) ***which is the wrong
data***.  It should load
http://www.manufacturingdivision.com/xml/weather.xml which is a completely
separate file on the server's disk and may contain different content.

I've actually performed this test and have a patch below which fixes both
of these problems.  This patch is against the pre-proposal-0003-no-psml
branch.

cvs diff -r pre-proposal-0003-no-psml PortletConfig.java (in directory C:
\CVSWORK\JetspeedDemo\jetspeed\src\java\org\apache\jetspeed\portal\)
Index: PortletConfig.java
===================================================================
RCS file:
/products/cvs/jetspeed/jetspeed/src/java/org/apache/jetspeed/portal/PortletConfig.java,v
retrieving revision 1.33.2.3
diff -u -r1.33.2.3 PortletConfig.java
--- PortletConfig.java   2000/10/16 22:55:04  1.33.2.3
+++ PortletConfig.java   2000/11/04 02:30:19
@@ -244,7 +244,13 @@
             Also, I think the test is really redundant, now that cache
works
             NOTE: localhost does not work always under NT. I'll try
127.0.0.1
             */
-            String serverName = "127.0.0.1";
+            /*  MDH
+                String serverName = "127.0.0.1";
+                Revert back to real server name because without it,
multi-hosting doesn't work
+                and some JVM SOCKS code does not support localhost or
127.0.0.1 at all.
+            */
+            String serverName = EngineContext.getInstance().getServerName
();
+
             int serverPort = EngineContext.getInstance().getServerPort();

             this.url = "http://" + serverName + ":" + serverPort + url;

______________________________________________________
Michael D. Harris - IBM Pervasive Computing - RTP, NC
E-Mail: [EMAIL PROTECTED] - IBM VNet: HARRISMD@IBMUSM27
Lotus Notes: Michael D Harris/Raleigh/IBM@IBMUS



--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Archives and Other:  <http://java.apache.org/main/mail.html>
Problems?:           [EMAIL PROTECTED]