paulb@390 | 1 | Preparing the Application
|
paulb@390 | 2 | =========================
|
paulb@379 | 3 |
|
paulb@212 | 4 | Use the build.py script in the tools/JavaServlet directory to create a Web
|
paulb@178 | 5 | application directory. Then, deploy the directory in the servlet container. For
|
paulb@178 | 6 | example:
|
paulb@178 | 7 |
|
paulb@212 | 8 | jython tools/JavaServlet/build.py examples/JavaServlet/SimpleApp.py \
|
paulb@212 | 9 | examples/Common/Simple/ \
|
paulb@212 | 10 | . \
|
paulb@290 | 11 | web.xml \
|
paulb@212 | 12 | $CATALINA_HOME/common/lib/activation.jar \
|
paulb@212 | 13 | $CATALINA_HOME/common/lib/mail.jar
|
paulb@178 | 14 |
|
paulb@290 | 15 | This identifies the handler (SimpleApp.py), the application package (Simple),
|
paulb@290 | 16 | the directory where the WebStack package is found (.), and the name of the
|
paulb@290 | 17 | template for the deployment descriptor (web.xml); it also specifies the
|
paulb@204 | 18 | library files which must also be deployed with the application (activation.jar
|
paulb@204 | 19 | and mail.jar from the Tomcat libraries in this case); it produces a directory
|
paulb@204 | 20 | called SimpleApp in the current directory. To deploy the Web application into
|
paulb@204 | 21 | a servlet container like Tomcat, a command like the following can be
|
paulb@204 | 22 | performed:
|
paulb@178 | 23 |
|
paulb@204 | 24 | mv SimpleApp/ $CATALINA_HOME/webapps/
|
paulb@178 | 25 |
|
paulb@178 | 26 | Upon starting or restarting the servlet container, an URL such as the following
|
paulb@178 | 27 | can be used to visit the application:
|
paulb@178 | 28 |
|
paulb@212 | 29 | http://localhost:8080/SimpleApp/
|
paulb@290 | 30 |
|
paulb@390 | 31 | Authentication/Authorisation with Apache Tomcat
|
paulb@390 | 32 | ===============================================
|
paulb@290 | 33 |
|
paulb@290 | 34 | In Apache Tomcat, it is not typically possible to use an authenticator with a
|
paulb@290 | 35 | WebStack resource without additional configuration being performed first:
|
paulb@290 | 36 |
|
paulb@290 | 37 | * The web.xml template should be replaced with the protected-web.xml
|
paulb@290 | 38 | template in the build.py command. This alternative template produces a
|
paulb@290 | 39 | special deployment descriptor which introduces role-based authentication for
|
paulb@290 | 40 | the application. Consequently, upon seeing that the application requires a
|
paulb@290 | 41 | user with a given role, Tomcat will prompt for the username/password details
|
paulb@290 | 42 | of a user with that role, and once such a user has been authenticated, the
|
paulb@290 | 43 | resulting user identity is then made available via the API to the
|
paulb@290 | 44 | application.
|
paulb@290 | 45 |
|
paulb@290 | 46 | * The server.xml configuration file in Tomcat should declare the protected
|
paulb@290 | 47 | application as a privileged context; for example:
|
paulb@290 | 48 |
|
paulb@290 | 49 | <Context path="/AuthApp" docBase="AuthApp" privileged="true"/>
|
paulb@290 | 50 |
|
paulb@290 | 51 | * The tomcat-users.xml configuration file should define suitable users and
|
paulb@290 | 52 | roles; for example:
|
paulb@290 | 53 |
|
paulb@290 | 54 | <role rolename="webstack"/>
|
paulb@290 | 55 | <user username="badger" password="abc" roles="webstack"/>
|
paulb@290 | 56 |
|
paulb@290 | 57 | Note that it is still possible for an authenticator to reject access to
|
paulb@290 | 58 | users even if they have the role stated in the special deployment
|
paulb@290 | 59 | descriptor.
|