jakarta-slide-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Jansz" <kevin.ja...@exari.com>
Subject Slide 2.1 working with Security on WebSphere
Date Mon, 24 Jul 2006 00:15:09 GMT
I wanted to share my experience with getting Slide working on WebSphere with
Security included. 

Thanks to the post on the slide-user list from Lynn Richards

Sorry this is a long post, but I know I would have found this level of
detail helpful a couple of days ago - a committer is welcome to add this to
the wiki?: http://wiki.apache.org/jakarta-slide/WebSphereSetup. I've put
detail and background in, so that even if following my details below don't
help, they may lead you in the right direction.

You will need:
* slide-server-2.1 source code - in order to make corrections and re-build. 
* IBM HTTP Server (IHS) and the Web Server Plugin

There are a two places (that I could find) in the code where the content
type is set to "text/xml; charset=\"UTF-8\"". The WebSphere servlet
container can't handle the quotes around the encoding. This needs to be
changed to "text/xml; charset=UTF-8". This works for Tomcat too, so perhaps
it should be committed in the server source? 

<     public static final String TEXT_XML_UTF_8 = "text/xml;
>     public static final String TEXT_XML_UTF_8 = "text/xml; charset=UTF-8";

<         res.setContentType("text/html; charset=\"UTF-8\"");
>         res.setContentType("text/html; charset=UTF-8");

1. / Path "Forbidden"
The issue where all paths appear to be "/" no matter what path is accessed
on Slide is due to the following code in
\WebdavUtils.java and a difference in implementation between WebSphere and
        String result = null;
        if (config.isDefaultServlet()) {
            result = req.getServletPath();
        } else {
            result = req.getPathInfo();

req.getServletPath() seems to always be "/" in WebSphere when the WebDAV
servlet is mapped to "/". The solution is to force slide to use the
getPathInfo() method by turning off the Default Servlet flag in the web.xml


2. The EAR file might be corrupt? web.xml validation
When you install a war file on WebSphere the web.xml is parsed and validated
against the spec. Any discrepancies with the spec will give you the
un-helpful error that the "EAR file might be corrupt". Add the detail below
to you opening node in the web.xml and make sure it is valid according to
the schema (using an editor such as XML Spy) before including it in the war

<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"

You'll find that all the <description> nodes are in the wrong place within
the <init-param> nodes - they should be the first child rather than the

More importantly is the security-constraint section. To get authentication,
you must define the constraint for all the possible http (WebDAV) methods.
The problem is according to the web.xml spec, the only valid http-method
values are: HEAD, GET, POST, PUT, DELETE, OPTIONS and TRACE. To have the
other WebDAV methods secure as well, leave the specific http-method
constraints out. This node is optional and if you don't specify any, all
Http methods will be secure and this will include the WebDAV extensions too.

    <!-- Uncomment this to get authentication -->
            <web-resource-name>DAV resource</web-resource-name>
            <!-- comment out the explicit http-method list 

1. Global Security
How to configure WebSphere with a Custom or LDAP realm is beyond the scope
of this mail list but with Security turned on, you will need to either Turn
off "Java 2 Security" or define a policy file for the slide web-app. 

With Java 2 security on, slide will get AccessControlException(s) when it
tries to check for the existence of things like its properties file (from
the "java.home" location? See Configuration.java - it will catch the
exception if the load fails but not if the file.exists() check is

2. WebServer Integration
It appears that when the WebSphere AppServer handles HTTP requests it
assumes the same default as the IBM WebServer, namely - content is only to
be expected and read for POST and PUT requests. This page on IBM's support
site is old but seems to apply for v6 as well:

To get the WebDAV extensions to HTTP working you need to configure the IBM
WebServer with the AppServer using IBM's WebServer Plugin. It's in the
Plugin where you're then able to allow content in all HTTP/WebDAV requests.
Ie "true" for 

	* AcceptAllContent *
	Specifies whether or not users can include content in POST, PUT,
GET, and HEAD requests when a Content-Length or Transfer-encoding header is
contained in the request header. You can specify one of the following values
for this attribute:
	* true if content is to be expected and read for all requests
	* false if content only is only to be expected and read for POST and
PUT requests.
	false is the default.

If you have version 6, with the WebServer and AppServer on the same machine
and the Server setup to propagate changes to the plugin-cfg.xml file, you
can set this flag in the Admin Console:
Web servers > webserver1 > Plug-in properties > Request and response
Check the box for - Accept content for all requests

I found integrating the AppServer with the WebServer via plugin not a simple
process. You should do this before installing slide and use the /snoop
servlet to check if things are working via the WebServer.

You could actually use a WebServer other than IBM's. The difference will be
that you may need to manually configure the Plugin in the AppServer and
WebServer and then when the Admin console updates the plugin-cfg.xml file
you may need to copy this to the place where the WebServer expects. 

After you install/deploy the slide.war (I gave it the enterprise application
name of "slide") you need to edit the Class Loading properties. 
Class loader mode = Parent Last  
WAR class loader policy = Application  

This avoids the problem of WebSphere v6 including an older version of JDOM
(1.0Beta7) in its lib folder as well as property file loading issues. 

Check that slide has been correctly associated with the WebServer Plugin: 
Enterprise Applications > slide > Map modules to servers
You should see something like:
It's important to see both the server and the webserver "module" in this

After starting the slide application it should be accessible via the
WebServer (port 80 by default). All access will have to be via the WebServer
and this should hopefully work without error and will be secure. 

Kevin Jansz

exari systems 
London | Melbourne | San Francisco

enterprise document assembly
Tel +61 (0)3 9621 2773
Fax +61 (0)3 9621 2776

To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org

View raw message