Installation Considerations for Portals
Composable Architecture Platform ships with support for JSR168 portlets. Portlets generally behave the same way as a servlet, although there are a number of significant restrictions that need to be taken into account when writing rules for portlets.
Firstly, portlets do not receive IP specific information such as the address of the remote host – nor can portlets set or access cookies. This means that to perform basic site protection or analysis, a site should use a combination of both portlet filtering and what can be referred to as “landing page” filtering.
Many portals (such as Apache JetSpeed) have a generic servlet that is always invoked and used to delegate the browsers post to the portlet engine. This generic servlet is ideal as the “landing page”. Other portals have an initial JSP or other means of receiving the initial access request to the portal, and from there, form the overall content. Whatever the method, you should always attempt to have an Composable Architecture Platform generic filter sitting at the very front of your portal.
Most portals, however, create intricate URLs that do not inform the rule writer about where the data posted from the browser is going to end up in the application. You are therefore required to install the Composable Architecture Platform portlet filter in front of each portlet (notice the distinction between the generic and portlet filter).
Each portlet filter should only be installed for portlets that are actually worth protecting. This is true both from an effort and performance perspective.
Installing the portlet filter
To install the portlet filter, you must edit the portlet.xml configuration file to wrap each individual portlet in the application. The illustration below shows how those tags are modified to include the filter.
First the <portlet-class> tag is modified to refer to the class software.tomorrow.engine.server.RulesEnginePortletFilter.
Next an initialization parameter is added to allow the filter to identify which portlet to invoke (the original class name now removed from the <portlet-class> tag).
These steps are repeated for each portlet that requires protection.
Important: It is common for portals to split their portlets into multiple applications. Please see the previous section Linking multiple applications together into a single server for instructions on how to link multiple applications together as a single managed entity.
Last updated
