| Support | Home | Word |
|
|
PageBox |
|
|
|
|
|
|
| Presentation | Install | User guide | Developer guide | Programming | Port | Repository | PageBox | Release notes |
PageBox for Java installationObjectiveThis page aims to answer three questions:
DownloadDocumentation: pageboxHtml.jar. Programming environment: pageboxPgm.jar. See the programming environment guide for a description of the programming environment of PageBox. PageBox for Java is distributed in three versions, the JWSDP version, the Tomcat 4/Axis version and the Tomcat 5/Axis version. The three versions are identical except for their RPC invoker, stubs and configuration files. Releasing three versions allows avoiding confusions and manual settings and helps getting started. JWSDPRepository
PageBoxPageBox is made of two parts:
Tomcat 5 / AxisStarting with version 0.1.0 there is a minor difference between the Tomcat 4 (servlet 2.3) and Tomcat 5 (servlet 2.4) versions. PageBox 0.1.0 and above can use the ServletRequestListener interface that was introduced in the servlet 2.4 specification. The version below uses this interface. The Tomcat 4 version does not use this interface. The only difference between both versions is located in the EventHandler class. Repository
PageBoxPageBox is made of two parts:
Tomcat 4 / AxisRepository
PageBoxPageBox is made of two parts:
WindowsCPUOn Windows NT, 2000, XP the measurement facility uses JNI and a dll called WindowsCPU.dll. WindowsCPU.zip contains the sources and the project used to compile WindowsCPU.dll with Visual C++ 6. DynDnsThis servlet emulates the DynDns server and can be used to test modifications of the PageBox and of the PageBox repository. The code is the same for JWSDP and for Tomcat/Axis
InstallationThe servlet container of the Java Web Services Developer pack (JWSDP) is Tomcat. Therefore the installation procedure for JWSDP is closely the same as for Tomcat/Axis. We call the root directory of the servlet container $TOMCAT_ROOT in the explanation below and the directory where you download the archives $INSTALL. JWSDP 1.3 is an all-in-one download containing the servlet container, the JAXP and the JAX-RPC support. Just go to http://java.sun.com/webservices/downloads/webservicespack.html, download JWSDP 1.3 and follow the installation instructions. JWSDP 1.5 does not include the servlet container. You can download a suitable version of Tomcat from http://java.sun.com/webservices/containers/tomcat_for_JWSDP_1_5.html. In the case of the Tomcat version you need to download Tomcat (servlet container), Xalan (JAXP support) and Axis (JAX-RPC support). We briefly describe now the setup of Tomcat/Xalan/Axis. Tomcat/AxisDownloadDownload Tomcat from http://jakarta.apache.org/tomcat/index.html. Download Xalan from http://xml.apache.org/xalan-j/index.html. Download Axis from http://ws.apache.org/axis/index.html. We tested PageBox 0.1.1 with Tomcat 5.0.28 or 4.1.31, Axis 1.1 and Xalan 2.5.2 or 2.5.1. You may use different versions of Tomcat and Xalan. If you use a different version of Axis you may need to regenerate the stub classes. TomcatInflate the Tomcat tar. AxisInflate the Axis tar. We call the Axis installation directory $AXIS_ROOT. Copy the archives stored in $AXIS_ROOT/lib or $AXIS_ROOT/webapps/axis/WEB-INF/lib into $TOMCAT_ROOT/common/lib. XalanInflate the Xalan tar. We call the Xalan installation directory $XALAN_ROOT. Copy xalan.jar from $XALAN_ROOT/bin into $TOMCAT_ROOT/common/endorsed. RepositoryThe installation consists of:
The simplest solution is to first inflate repository.war into $TOMCAT_ROOT/webapps/repository with the command:
Then edit $TOMCAT_ROOT/webapps/repository/WEB-INF/web.xml. You should be displayed this (sections that you do not need to customize skipped):
You must define the initial logging level. In the web.xml example above the logging is set to info (informational or intensive). In info mode the Repository logs error, warning and information messages. You can also set the initial logging level to warn. In warn mode the Repository logs only error and warning messages. Once the Repository application server is started you can change the logging level on the audit form. ceiling is used for relayed deployment. In this model the Repository sends sets of target PageBoxes to relay PageBoxes. These PageBoxes in turn send sets of target PageBoxes to other relay PageBoxes. Because many sources deploy at the same time using different network paths the deployment is shorter for big archives. For small archives it is not necessarily the case because the relay PageBoxes must notify the Repository about the success of their deployments. The optimal ceiling value depends on the bandwidth between the PageBoxes and the Repository. The recommended range is between 1500 and 63000 bytes. relaytime is used for relay management. The archive is set in "maybe" status for all PageBoxes deployed by relay PageBoxes and then set in "installed" status by notify once the relay PageBoxes have completed their deployments. A Repository user cannot modify an archive in "maybe" status. After relaytime the Repository retries the deployment and sets the status according to the deployment status. The optimal value depends on two factors:
The recommended range is between 5 and 60 minutes. The default value is 60 minutes. period defines the time in seconds between two retries. At a retry the Repository
The default value of period is 900s (15mn). token-period is only used when PageBoxes registered on this Repository use the token API. token-period represents the time in milliseconds between the emission of two tokens. By default token-period equals 2000 (2 seconds). We recommend setting the Repository listener with <listener><listener-class>Repository.EventHandler</listener-class></listener>. If you do not set the listener, set the subscribe servlet with <load-on-startup>110</load-on-startup>. Web serviceStarting with PageBox 0.0.10 the Repository can accommodate different RPC invokers and service access points. The protocol recommended for interoperability on Internet is SOAP 1.2. However you can implement your own protocol using for instance XML RPC, raw HTTP, RMI or raw TCP. Two parameters are defined in version 0.0.10, which should be sufficient for HTTP protocols:
Version 0.0.10 is packaged in three flavors to help getting started. We give now the values to setup for JWSDP, Tomcat/Axis and raw HTTP:
The default mode is JWSDP. The default values are therefore:
Repository directoriesYou need to customize the paths:
When a Publisher publishes a Web archive the archive is first stored in uploaddir. Then the Repository computes the difference between the old version of the archive stored in downloaddir and the new version stored in uploaddir. Next the Repository stores the difference in deltadir. Eventually the Repository removes the old version and moves the new version of the archive into downloaddir. If a subscribed PageBox has already the old version of the archive, the Repository deploys the difference from deltadir. If a subscribed PageBox does not have the old version of the archive, the Repository deploys the full archive from downloaddir. Except during publications the uploaddir should be empty. We present now the structure of the files written and updated by the Repository for troubleshooting purpose: you should never modify these files by hand. archives.xmlarchives.xml describes the archives published on a Repository. archives.xml is displayed by publish.jsp. It has the following format.
Each archive is represented by an archive element that contains:
subscribers.xml and asubscribers.xmlsubscribers.xml describes the Repository subscribers and the deployment status of the archives on the subscribed PageBox. subscribers.xml is displayed by subscribe.jsp. asubscribers.xml describes the archive subscribers of the Repository and the deployment status of the archives on the subscribed PageBox. asubscribers.xml is displayed by asubscribe.jsp and aselect.jsp. subscribers.xml and asubscribers.xml have the same format [Axis example]:
Each subscription is represented by a subscriber element that contains:
The status of a Web archive deployment on a subscribed PageBox is represented by an archive element:
Repository securityRepository security relies on the user authentication and if needed on SSL. The default security model (described in the web.xml listed above) assumes three roles:
The web.xml above uses basic authentication and the Tomcat user database. You can set the user database in $TOMCAT_ROOT/conf/tomcat-users.xml with:
In this example we define a pagebox account for the administration of Tomcat, a tester account to manage the log and all publications and subscriptions, two publisher accounts, publisher and publisher2 and two subscriber accounts, subscriber and subscriber2. Note: You must define the tester account with the pagebox-publisher and pagebox-subscriber roles to allow it to manage publications and subscriptions SSLPrincipleThe Secure Socket Layer (SSL) has three functions:
The Repository automatically detects if SSL is in place with the following snippet:
Getting startedSSL setting is well described in a Tomcat how-to. Here is a summary. To use SSL you must
In Java key pairs and certificates are stored in keystore files. For testing you can create the keystore, a key pair and a certificate with the following command:
keytool asks many questions. If you want to simplify the subsequent Tomcat configuration step use the default password, which is "changeit" for the keystore and the key. Put down the Repository host name when keytool asks you to enter your first name and last name. Otherwise, you will encounter "HTTPS hostname wrong error" exception. The Repository host name is:
The command above creates the default key if it does not already exist in a file named .keystore in the user's home directory, which is on Win 2K and XP Documents and Settings\username. Now you can configure Tomcat to use SSL. Define a SSL connector in $TOMCAT_ROOT/conf/server.xml:
If you want to prevent users to access the Repository without SSL comment the HTTP connector definition. If you use a non-default keystore specify the keystore path in a keystoreFile attribute of the Factory element. If your keystore or certificate has a password different of changeit specify the password in a keystorePass attribute of the Factory element. Production concernDo not use “keytool -genkey -alias repository -keyalg RSA” on a production system. The reason is that this command generates a self-signed certificate, which basically says: “I certify that I am what I pretend to be”. You need a certificate from a certificate authority. To get this certificate:
The simplest solution is to use an Internet Certificate Authority, the most famous being Verisign and Thawte. You can also use InstantSSL. These CAs may grant you free certificates for testing purpose. For a trustable certificate you must pay. It has to be said that in this particular case that charging someone for a certificate is the cheapest way to get evidence that a requestor is who it claims to be: (1) the request knew a credit card number and expiration date (2) the requestor did not complain when it was charged for the service. Another solution is to run a constellation certificate authority, the most popular commercial products being Netscape Management System and Microsoft Certificate service. The cheapest solution consists in using the CA command of OpenSSL. A cookbook explains how to do that.
On a production environment do not use the default password. If a malicious user can read your keystore and guess its password it can use your private key and your security is compromised. PageBox checkingThe PageBox may also use SSL. In this case the Repository checks the certificate presented by the PageBox to verify that the requestor is a valid PageBox and not a fake server. More precisely the Repository verifies that the issuer of the certificate presented by the PageBox is defined in a special keystore called a trust store. By default this keystore is a file in the Sun jks format. A system property, javax.net.ssl.trustStore specifies its path and another system property javax.net.ssl.trustStorePassword specifies its password. For convenience and consistency we defined two context parameters in the Repository web.xml:
Note that these parameters are JVM-wide. If you do not define javax.net.ssl.trustStore at Tomcat startup nor trust-store in the Repository web.xml then the implementation will use a $JAVA_HOME /lib/security/jssecacerts trust store if it exists and a $JAVA_HOME /lib/security/cacerts if not. Here $JAVA_HOME is the installation path of the runtime ($JDK_JAVA_HOME/jre). cacert contains a limited number of trusted root certificates that you can display with the command:
The use of SSL for PageBox implies the same tasks as for the Repository:
In the same way as for the Repository you can use self-signed certificates for the Tomcat hosts of the subscribed PageBox. However because each self-signed certificate has a unique issuer, the certificate itself, you must enter all Tomcat certificates in the trust store, which might be the simplest solution for testing but is inconvenient in a production environment. In a production environment PageBox administrators should query a certificate to a constellation certificate authority. Then the administrator of a constellation Repository only needs to add the certificate of the certificate authority to the trust store. In both cases:
To create the trust store you can use this command:
To export a certificate stored in a keystore (typically a self-signed certificate) use this command:
To import a certificate in the trust store use this command:
DynDnsDynDns setting is defined by the following context parameters in the Repository web.xml:
If you want to use the dynamic registration facility you need:
Your host may have more than one IP address. To identify this IP address you can specify the local name for this IP address (specified in /etc/hosts on Linux/Unix and on \windows\System32\drivers\etc\hosts on Windows) or specify the interface name, for instance ppp0 for a dialup link on Windows. To list the interfaces defined on your system use the ipconfig command or use this Java class. SandboxStarting with PageBox for Java version 0.0.7 the Repository is tested with Java 2 security. To use this facility you must:
catalina.policyYou must restrict default permissions (that allow for instance to write everywhere) and give all permissions to PageBox, PageBoxLib and to extension archives. We recommend to comment in default permissions (in grant { ... })
Your Web applications will still be able to change files in their directories because Web applications are given a read/write/delete FilePermission for files and directories in their document root. If you need to grant file permissions to specific files you can add lines like:
Note for Window users: Use slashes and not backslashes in the file path. You should also comment in default permissions Runtime permissions such as:
You must grant all permissions to Repository:
Granting permissions to Repository is not an issue because you control this archive that you download and install and because you can check and recompile its sources. StartStart WSDP with:
PageBoxThe installation consists of:
PageBox libraryThere are two ways to use the PageBox library:
With the latter method you must include the pageboxLib.jar in WEB-INF/lib of the web archives of PageBox and of all Web applications deployed with PageBox that provide an installation class or use the PageBox API. Therefore the deployment takes more time and uses more bandwidth and the Application server uses more memory. To install the PageBox library as a shared library on JWSDP, copy pageboxLib.jar into $TOMCAT_ROOT/shared/lib. To install the PageBox library as a shared library on Tomcat/Axis, copy pageboxLib.jar into $TOMCAT_ROOT/common/lib. web.xmlThe simplest solution is to first inflate pagebox.war into $TOMCAT_ROOT/webapps/pagebox with the command:
Then edit $TOMCAT_ROOT/webapps/pagebox/WEB-INF/web.xml. You should be displayed this (sections that you do not need to customize skipped):
We recommend setting the PageBox listener with <listener><listener-class>PageBox.EventHandler</listener-class></listener>. If you do not set the listener, set the Update servlet with <load-on-startup>110</load-on-startup>. We describe below the context parameters you probably need to set. Security parametersThe PageBox security relies on the user authentication. The default security model (described in the web.xml listed above) assumes a pagebox-user role that allows
The web.xml uses basic authentication and the Tomcat user database. You can set the user database in $TOMCAT_ROOT/conf/tomcat-users.xml with:
workdirworkdir is the directory where you must define rules.xml (described below) and where log.html and PbArchives.xml are written and updated. PbArchives.xml describes the archives installed on a PageBox. PbArchives.xml is displayed by update. It has the following format [JWSDP case].
Each archive is represented by an Archive element that contains:
We present now the structure of PbArchives.xml for troubleshooting purpose: you should never modify this file by hand. infoYou must define the initial logging level. In the web.xml example above the logging is set to info (informational or intensive). In info mode the PageBox logs error, warning and information messages. You can also set the initial logging level to warn. In warn mode the PageBox logs only error and warning messages. Once the PageBox application server is started you can change the logging level on the audit form. Dynamic deployment parameters
Once the deployed archive has been inflated and its Install class has been invoked the PageBox can call the dynamic configuration facility of the Application server. The dynamic configuration requires four context parameters in web.xml:
PageBox.TomcatInstall is the Tomcat 4 installer. If the base URL of your Tomcat installation is http://mysite:8080 the configuration facility URL is http://mysite:8080/manager. In case of Tomcat 4 install-user must identify a user with a manager role. See the porting guide to develop a class to call the dynamic configuration of another Application server. DynDns
If you want to use the dynamic registration facility you need:
Your host may have more than one IP address. To identify this IP address you can specify the local name for this IP address (specified in /etc/hosts on Linux/Unix and on \windows\System32\drivers\etc\hosts on Windows) or specify the interface name, for instance ppp0 for a dialup link on Windows. To list the interfaces defined on your system use the ipconfig command or use this Java class. Token APIThe Token API implementation has only one parameter, token-period. When token-period has expired the Token API considers that the frame was lost and asks to the previous PageBoxes on the ring for the frame. By default token-period equals 2000 (2 seconds). token-period must be higher than the highest token-period of the Repositories from which this PageBox deployed archives using the token API. SSLThe explanation for the SSL setting in PageBox is pretty much the same as for the SSL setting in the Repository. PrincipleThe Secure Socket Layer (SSL) has three functions:
The PageBox automatically detects if SSL is in place with the following snippet:
Getting startedSSL setting is well described in a Tomcat how-to. Here is a summary. To use SSL you must
In Java key pairs and certificates are stored in keystore files. For testing you can create the keystore, a key pair and a certificate with the following command:
keytool asks many questions. If you want to simplify the subsequent Tomcat configuration step use the default password, which is "changeit" for the keystore and the key. Put down the PageBox host name when keytool asks you to enter your first name and last name. Otherwise, you will encounter "HTTPS hostname wrong error" exception. The PageBox host name is:
The command above creates the default key if it does not already exist in a file named .keystore in the user's home directory, which is on Win 2K and XP Documents and Settings\username. Now you can configure Tomcat to use SSL. Define a SSL connector in $TOMCAT_ROOT/conf/server.xml:
If you want to prevent users to access the PageBox without SSL comment the HTTP connector definition. If you use a non-default keystore specify the keystore path in a keystoreFile attribute of the Factory element. If your keystore or certificate has a password different of changeit specify the password in a keystorePass attribute of the Factory element. Production concernDo not use “keytool -genkey -alias repository -keyalg RSA” on a production system. The reason is that this command generates a self-signed certificate, which basically says: “I certify that I am what I pretend to be”. You need a certificate from a certificate authority. To get this certificate:
The simplest solution is to use an Internet Certificate Authority, the most famous being Verisign and Thawte. You can also use InstantSSL. These CAs may grant you free certificates for testing purpose. For a trustable certificate you must pay. It has to be said that in this particular case that charging someone for a certificate is the cheapest way to get evidence that a requestor is who it claims to be: (1) the request knew a credit card number and expiration date (2) the requestor did not complain when it was charged for the service. Another solution is to run a constellation certificate authority, the most popular commercial products being Netscape Management System and Microsoft Certificate service. The cheapest solution consists in using the CA command of OpenSSL. A cookbook explains how to do that.
On a production environment do not use the default password. If a malicious user can read your keystore and guess its password it can use your private key and your security is compromised. Repository checkingThe Repository may also use SSL. In this case the PageBox checks the certificate presented by the Repository to verify that the requestor is a valid Repository and not a fake server. More precisely the PageBox verifies that the issuer of the certificate presented by the Repository is defined in a special keystore called a trust store. By default this keystore is a file in the Sun jks format. A system property, javax.net.ssl.trustStore specifies its path and another system property javax.net.ssl.trustStorePassword specifies its password. For convenience and consistency we defined two context parameters in the PageBox web.xml:
Note that these parameters are JVM-wide. If you do not define javax.net.ssl.trustStore at Tomcat startup nor trust-store in the PageBox web.xml then the implementation will use a $JAVA_HOME /lib/security/jssecacerts trust store if it exists and a $JAVA_HOME /lib/security/cacerts if not. Here $JAVA_HOME is the installation path of the runtime ($JDK_JAVA_HOME/jre). cacert contains a limited number of trusted root certificates that you can display with the command:
The use of SSL for the Repository implies the same tasks as for PageBox:
In the same way as for the PageBox you can use self-signed certificates for the Tomcat hosts of the Repositories. However because each self-signed certificate has a unique issuer, the certificate itself, you must enter in the trust store the Tomcat certificates of all Repositories to which the PageBox is likely to be subscribed. In a production environment Repository administrators should query a certificate to a constellation certificate authority. Then the administrator of a constellation PageBox only needs to add the certificate of the certificate authority to the trust store. In both cases:
To create the trust store you can use this command:
To export a certificate stored in a keystore (typically a self-signed certificate) use this command:
To import a certificate in the trust store use this command:
rules.xmlrules.xml allows the PageBox administrator to define the subscriber, the Repositories and the publishers that she trusts and how much she trusts these subscribers, Repositories and publishers. Here is an example of rules.xml [Tomcat/Axis case]:
rules.xml contains four sections:
Root sectionThe Install.class must implement the following interface:
Where PageBoxAPI has the following signature:
Where
SQL connections are established using the parameters defined in a JDBCinfo object:
The Install.class can only write or update files in the archPath directory, use the archive database and write log messages of interest for the PageBox administrator using the log object. We describe the resources usage in the resource section below. For more information read the user guide. Elements in the root section allow the administrator to set the parameters used by PageBox to invoke the Install.class of the archives.
Starting with version 0.0.7, PageBox manages a database per application. The name of this database is PageBox_working_directory + "_" + Archive_directory. The actual setting depends on the url format:
The PageBox administrator can set scripts called at archive installation and uninstallation, whose paths are dbcreate and dbdrop. These scripts are called with two parameters:
We give four examples of scripts in pagebox.war, dbcreate.bat and dbcreate.sh to create a mysql database and dbdrop.bat and dbdrop.sh to drop a mysql database. Here is dbcreate.bat (Windows):
Here is dbcreate.sh (Linux, Unix):
Here is dbdrop.bat (Windows):
Here is dbdrop.sh (Linux, Unix):
dbcreate is primarily designed to create an archive-specific database and dbdrop is primarily designed to drop this archive-specific database. However a PageBox administrator can use them to perform other initialization (dbcreate) and cleanup (dbdrop) tasks. An initialization script can parse an XML file defined with a well-known name in the archive directory. The publisher may use this facility to require archive-specific tasks. target is also used to define where to inflate the Web archive. Because of that target is a mandatory element. Other elements in the root section are optional. resources sectionThe resources section is optional. Here is an example:
The resources section allows the Install.class programmer to update the archive’s web.xml to use the Application server resources. The resources parameter of the install and uninstall parameters is a Map whose key is the resource name and value is a ResourceInfo object. The ResourceInfo class is defined like this:
Where:
Here is how PageBox interprets the resource section to build the resources Map:
The install class can update web.xml with the following snippet:
This is needed to link the Web archive to a resource defined in the Application server configuration. Here is an example. You can add this snippet in the Engine or in the Host element of $TOMCAT_ROOT/conf/server.xml:
See the Tomcat documentation for more information. In the same way the PageBox API allows retrieving resources by name. For instance the installed archive can use the resource configured by install.class with something like:
The PageBox administrators and the archive programmers must use the same resource naming conventions. When the PageBox administrators choose to provide resource support, they should provide;
extensions sectionThe extensions section is optional. Here are the extension elements:
An extension is a facility provided by the PageBox administrator to allow archives to perform potentially insecure tasks in a controlled manner. An archive can instantiate an extension with the getExtension method:
Where
When the archive calls the getExtension method the PageBoxAPI creates an object of the associated ext_class type with a constructor whose single parameter is of the parmClass type and contains the parm object. The extension must implement the ExtensionIF interface defined like this:
The archive calls this call method through a wrapper that also implements the ExtensionIF interface. The Epimetheus example version 0.0.3 and above calls an extension that lists the host serial and parallel ports. repositories sectionThe repositories section contains one or many repository elements and a default elements. A repository element may contain a subscriber and a publishers section. A publishers section contains one or many publisher elements. The most important elements are publisher, default and repository, which have an object structure:
A publisher can contains an allow element, an extensions and a resources sections. A repository and the default can also contain an allow element, an extensions and a resources sections but
publishers sectionEach publisher is represented by a publisher element that contains:
default elementThe PageBox default settings are defined in a default element. Because the default element inherits from the publisher element it may also have an allow element, an extensions and a resources sections with the same meaning as described in the publisher element. The default element can also contain:
Version 0.0.10 and above are packaged in three flavors to help getting started. We give now the values to setup for JWSDP, Tomcat/Axis and raw HTTP:
The default mode is JWSDP. The default values are therefore:
repositories sectionEach repository is represented by a repository element. Because a default repository inherits from the publisher element it may also have an allow element, an extensions and a resources sections with the same meaning as described in the publisher element. A repository element can also contain:
subscriber sectionThe subscriber section contains the user name and password of the subscriber allowed to subscribe the PageBox to a Repository. This information is used for two purposes:
The repositories data are used in combination. Therefore their usage is explained in a Security and Permissions topic. SecurityDeploy and Undeploy requests contain:
The diagram below shows how PageBox uses the repositories data.
The PageBox first checks if the Repository that deploys or undeploys is defined in the memory representation of rules.xml. If the Repository is defined the Pagebox checks if the request is issued on behalf of the subscriber specified in rules.xml (not depicted on the diagram). If the request is not issued on behalf of this subcriber the request is rejected. Otherwise the PageBox checks if the archive publisher is defined for this Repository. If it is the case the PageBox uses the allow element of the publisher to setup the deployment right. If the publisher is not defined for this Repository the PageBox uses the allow element of the Repository to setup the deployment right. If the Repository that deploys or undeploys is not defined in the memory representation of rules.xml the PageBox checks if the unauthenticated element in default is set to true. If it is not the case the request is rejected. Otherwise the PageBox uses the allow element of default to setup the deployment right. It is also possible to not define the allow element at the publisher or at the Repository level. The PageBox uses the most specific allow. If the deployment right is "none" the request is rejected and the PageBox returns an error "Not allowed to [un]deploy". If the deployment right equals "copy" the PageBox inflates the archive and calls the Application server deployment. If the deployment right equals "install" the PageBox inflates the archive, runs the dbcreate script, calls the archive Install.class and then the Application server deployment. The PageBox builds resource and extension sets that contain extensions and resources defined at the default, repository and publisher level. Do not define a resource or an extension at multiple levels. An archive can only use resources defined in the resource set and extensions defined in the extension set. ExtensionsInstall extensions at the same place as pageboxLib.jar:
With the latter method you must include extension archives in WEB-INF/lib of the web archives of all Web applications deployed with PageBox that use the extension. Therefore the deployment takes more time and uses more bandwidth and the Application server uses more memory. To install an extension archive as a shared library on WSDP, copy the extension archive into $TOMCAT_ROOT/shared/lib. SandboxPageBox for Java version 0.0.7 and above implement a Java 2 security: Install.class runs with two permissions:
Which means that Install.class can read properties and change files in the directory where the archive was inflated. To use this facility you must:
catalina.policyYou must restrict default permissions (that allow for instance to write everywhere) and give all permissions to PageBox, PageBoxLib and to extension archives. We recommend to comment in default permissions (in grant { ... })
Your Web applications will still be able to change files in their directories because Web applications are given a read/write/delete FilePermission for files and directories in their document root. If you need to grant file permissions to specific files you can add lines like:
Note for Window users: Use slashes and not backslashes in the file path. You should also comment in default permissions Runtime permissions such as:
You must grant all permissions to PageBox and PageBoxLib (archive stored in $TOMCAT_ROOT/shared/lib):
Granting permissions to PageBox and PageBoxLib is not an issue because: You control these archives: you download and install them You can check and recompile their sources PageBoxLib actually require the most sensitive permissions:
Without a correct security setting a malicious publisher can break your hosting system or use it to spread viruses. Therefore we recommend setting security when you cannot trust your Repository at 100%. We also recommend checking your security. We give an example in Pandora 0.0.2 made of the CheckSandbox, CheckClassLoader, CheckLoaded, and CheckLoad classes. This example checks that a PageBox hosted application cannot read and write files everywhere, create a class loader, run native code or commands. StartStart WSDP with:
Resource probeOn Windows NT, 2000, XP the resource probe of the default implementation uses JNI and a dll WindowsCPU.dll. You must add this dll directory in the PATH before starting Tomcat. Customized versions of PageBox may also use shared libraries in their resource probes. In such cases add this shared library directory to the shared library path before starting Tomcat. The shared library path variable is frequently called LD_LIBRARY_PATH. Check the JNI and the Operating System documentation in case of doubt.
Contact:support@pagebox.net |
