Let me see if I can clarify a little... The first thing to note is what the difference is between Domain.xml and web.xml. Essentially they configure different things. Slide consists of a java managed bean (the core) which does most of the work and also comes with two servlets (Slide and Manager) which are layers above the bean. The Slide servlet is an interface to the bean and is in turn driven by a "servlet container" such as Tomcat. Think of a servlet as a "little server". Imagine setting up a whole lot of dedicated webservers that specialise in some particular job. You might have a servlet to serve web pages, but another is a program that reads email. With Apache, you'd do this with one huge web server, a series of Virtual Hosts and some CGIs. Servlets are simply dedicated servers for a single given task and are usually programs (such as an IMAP to HTTP program instead of a PHP IMAP script running in the same server as everything else). However it is not neccessary to use the servlet to use slide. You could interface directly to the slide API and build your own system using slide's core (DAV) functionality, it's data storage systems etc. In this case you would _still_ need a Domain.xml file to configure the "domain" (the way data is layed out, permissions, user passwords etc), but would probably not use the supplied web.xml. It governs security within the domain - who can do what to what nodes within the hierarchy, who is given which "role" etc. Web.xml (a "deployment descriptor" is something you need whenever you deploy a servlet (any servlet) and configures the servlet - it is somewhat like a <VirtualHost> section in apache httpd.conf file. It typically lists things like the welcom (index) file names, directory permissions etc. See chapters 9, 10 and 11 of the java servlet spec available from http://java.sun.com/products/servlet/ for more information about web.xml files. As you can see, these two files have to be set up for a proper security configuration. 1) The Domain.xml configuration file currently contains the following roles definitions <!-- Roles definition --> <role name="admin">slideroles.basic.RootRole</role> <role name="user">slideroles.basic.UserRole</role> <role name="guest">slideroles.basic.GuestRole</role> This section is a declaration - simply a list of the _roles_ to be used for the domain. It associates a "name" (login ID) with a role as recognised by slide such as slideroles.basic.RootRole. As you can see, we identify a role by naming its class. The classes for roles (such as slideroles.basic.RootRole) live in the src\roles\slideroles\basic\ directory and they're essentially almost-vanilla subjectNode classes. Anyway the above section says "if someone logs in with username "admin", associate them with the class slideroles.basic.RootRole (and so on). Of course, if you have decided to have your authentication done by the servlet container (tomcat and you are not using SlideRealm, say), the roles are assigned by the container (eg tomcat-users.xml). In that case the Roles-definition above is not used. On the other hand, if you configure tomcat with SlideRealm, tomcat will refer user identification to slide and slide will use the Domain.xml configuration file to do that. 2) Later in Domain.xml we see <!-- /users represents the unauthenticated user --> <objectnode classname="org.apache.slide.structure.SubjectNode" uri="/users"> <permission action="/actions" subject="~"/> <permission action="/actions" subject="guest" inheritable="true" negative="true"/> <permission action="/actions/read" subject="user" inheritable="false"/> [SNIP - permissions group example here] <!-- /users/root represents the administrator --> <objectnode classname="slideroles.basic.RootRoleImpl" uri="/users/root"> <revision> <property name="password">root</property> </revision> </objectnode> [SNIP - similar definitions for the other two roles here] </objectnode> Which configures rights for the subjectnode (or "directory" in this case) "/users". The <permissions> tags enable users with the given roles to apply items from the "/actions" node (which includes read, write etc). For example the role "guest" has _negative_ access to /actions and this is inherited by any node beneath this thus denying guest access to /users/*. However an authenticated user (role "user") can access /actions/read in uri /users, however this right is not automatically inherited, so that fred can read the /users contents, but not /users/jane (by default). However the first <permission> tag gives a user access to all actions when in their own area. The second block above defines a property for the administrator (password=root, though this is only used when authenticating with SlideRealm rather instead of using tomcat.users). The node is identified both by it's role class (slideroles.basic.RootRoleImpl) and uri (/users/root). If your authentication is being done by tomcat-users.xml, the second block here is not used as the passwords are defined in tomcat-users.xml, however the first block (<permission ...> section) is still used to configure access rights to the nodes in a domain. 3 The security constraint section of web.xml looks like this <!--security-constraint> <web-resource-collection> <web-resource-name>DAV resource</web-resource-name> <url-pattern>/*</url-pattern> <http-method>COPY</http-method> [SNIP - other methods here] </web-resource-collection> <auth-constraint> <role-name>root</role-name> <role-name>guest</role-name> </auth-constraint> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>Manager</web-resource-name> <url-pattern>/manager/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>root</role-name> </auth-constraint> </security-constraint> And (as you can see) is commented out (!-- ....). The first thing to do is remove the !-- and the --> which you'l find later in the file. When you uncomment the section, the servlet will serve requests to appropriate people. Look at the second section first as it is perhaps more familiar to most people. It tells the manager servlet to serve GET and POST requests from someone whose role is "root". In fact it says that a request for (say) www.myserver.com.au/manager/index.html [post request] or www.myserver.com.au/manager/index.html?index=1 [a get request] is acceptable if you're logged in as a user that has role root. Now, HTTP requests are almost always GET and PUT (though there are actually a few others that are rarely used). WebDAV adds a whole lot more types of requests. A WebDAV-aware "browser" can send a COPY request (for example) and the first of the two blocks above allows this to be served to root and guest users for (say) www.myserver.com.au/index.html Hope this helps! Peter
