How to Set Up a Request Logging Servlet Filter

I developed a servlet filter that is capable of logging the request data that a client sends to the PeopleSoft servlets.  I did this project to better familiarize myself with Java as well as to get more comfortable developing at the web-tier.  This servlet filter can be useful for keeping track of what users are doing in your PeopleSoft applications.  I will admit that the code that I am releasing here is pretty raw and should be used with caution.  I am mostly putting this out here for documentation purposes.

CLICK HERE to download the project.

Extract the zip and you should see the following files:

Take the folder named “custom” and place it in the following directory:

%PS_CFG_HOME%\webserv\*your_domain_name*\applications\peoplesoft\PORTAL.war\WEB-INF\classes\com\peoplesoft\pt

Take the folder named “RequestLoggerFilter” and place it in the following directory:

 %PS_HOME%\sdk

Navigate to and open up the web.xml file.  The web.xml file is located in the following directory:

%PS_CFG_HOME%\webserv\*your_domain_name*\applications\peoplesoft\PORTAL.war\WEB-INF

Copy the text from the downloaded file named “webxml.txt” and paste the text into your web.xml file.  Paste in the text so that it is the first to show up in the web.xml file.  For my environment, I pasted the filter before the delivered “psfilter”.  After saving the web.xml file, **you will need to bounce the web server.**

After bouncing the web server, login to the PIA and navigate around to some arbitrary components.  I logged in as the PS user and navigated to the “Change my Password” page. Now open up the following directory on the webserver:

%PS_CFG_HOME%\webserv\*your_domain_name*\

You should see a csv file that is prefixed with “PSM_REQLOG_”

Open this file up and it will contain request logs.  Since I logged in as the PS account and navigated to the “Change My password’ page, my log file contains the following:

There were two lines that showed up for this transaction.  The first one was for the call to the “psp” servlet and the second one was for the call to the “psc” servlet.  If you are interested in logging the requests for only a single servlet, then scroll to the “Configuring the URL Pattern” section.  The third column of the output file is the contents that are stored in the USERID session variable that is defined on the web server.  This value contains the PeopleSoft ID and IP address that made the request.  Scroll down to the “Attributes Parameter” section to get more information on logging these types of values.

Below is an explanation of the different input parameters for this servlet filter.  These parameters can be used to specify the type of requests and information that you are interested in logging.

 

ContentTypes Parameter:

This parameter is used to specify which requested content types that you want to be logged. You can specify a single content type, multiple content types (csv format), or a * to log all content types. A typical PeopleSoft URL will have the following structure:

http://server/servlet_name/sitename/portalname/nodename/content_type/content_id?content_parm

The content_type section of the URL is usually denoted by a single character. This single character representation of the content type shall be specified for the ContentTypes parameter. So if you want to log component content types, then the ContentTypes parameter will look like this:

<init-param>

<param-name>ContentTypes</param-name>

<param-value>c</param-value>

</init-param>

Or if you want to log component, script, and query content types, then the ContentTypes parameter will look like this:

<init-param>

<param-name>ContentTypes</param-name>

<param-value>c,s,q</param-value>

</init-param>

Or you can log all content types with the following setting:

<Init-param>

<param-name>ContentTypes</param-name>

<param-value>*</param-value>

</init-param>

Search “URL Format for PeopleSoft Pure Internet Architecture Content Types” in PeopleBooks to get a listing of the different content types.

 

LogQueryStr Parameter:

This parameter is used to specify whether or not you want to log the URL query parameters that get sent for some requests. A typical PeopleSoft URL will have the following structure:

http://server/servlet_name/sitename/portalname/nodename/content_type/content_id?content_parm

The content_parm section of the URL refers to the query parameters. If you would like for this information to be logged, then specify a 1 for the LogQueryStr parameter as follows:

<Init-param>

<param-name>LogQueryStr</param-name>

<param-value>1</param-value>

</init-param>

Or if you do not want this information to be logged, then you can specify a 0 for the LogQueryStr parameter as follows:

<Init-param>

<param-name>LogQueryStr</param-name>

<param-value>0</param-value>

</init-param>

 

LogBody Parameter:

This parameter is used to specify whether or not you want to log the request message body that gets sent for some requests. Information gets sent in the request body for actions such as logging in, saving a component, or clicking search on a search page. You can capture this information by specifying a 1 for the LogBody parameter as follows:

<Init-param>

<param-name>LogBody</param-name>

<param-value>1</param-value>

</init-param>

If you do not want this information to be logged, then you can specify a 0 for the LogBody parameter as follows:

<Init-param>

<param-name>LogBody</param-name>

<param-value>0</param-value>

</init-param>

Note: This functionality should be used with caution. Any request body data that is captured will be logged as plain text. This means that any sensitive data that gets sent with a request will be stored as plain text in the log file.

 

Attributes Parameter:

This parameter is used to capture session variable information that is stored on the web server during a given request. You can specify the session variable names (csv format) that you would like to capture the value for. The names and existence of the session variables can potentially change with each PeopleTools version release. So if you are unsure of the specific session variable names that exist for your current PeopleTools release, then you can specify a * to dump all of the session name-value pairs for requests.

<Init-param>

<param-name>Attributes</param-name>

<param-value>*</param-value>

</init-param>

After reviewing the captured name-value pairs, you can then specify the names of the session variables that you would like to capture. In the 8.55.06 PeopleTools release that I tested this servlet filter on, there exist session variables name USERID and ROLES (along with other variables). To log the values of these session variables for each request, then you can specify the Attributes parameter as follows:

<Init-param>

<param-name>Attributes</param-name>

<param-value>USERID,ROLES</param-value>

</init-param>

 

FileName Parameter:

This parameter is used to specify the output filename that the logs will get written to. The actual output log filename will be the value that is given for this parameter with the current date (MM_DD_YY format) appended to it. The generated output logs will be saved in csv format.

 

Configuring the URL Pattern:

If you only want the requests to be logged when a particular servlet is called, then you can specify this with the filter-mapping configuration. A typical PeopleSoft URL will have the following structure:

http://server/servlet_name/sitename/portalname/nodename/content_type/content_id?content_parm

You can filter what is logged by specifying the servlet_name section of the URL in the filter-mapping configuration. If you want only the requests for the “psc” servlet to be logged, then you can configure the filter-mapping like this:

<filter-mapping>

<filter-name>RequestLoggerFilter</filter-name>

<url-pattern>/psc/*</url-pattern>

</filter-mapping>

Or you can specify /* to log the requests made to all of the different servlets:

<filter-mapping>

<filter-name>RequestLoggerFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

Refer to PeopleBooks for a listing of the available delivered servlets.

---

Most of the functionality that this servlet filter provides can be achieved via configuration on the WebLogic server.  However,  coding and implementing this functionality myself was a great learning experience.  I believe that this example servlet filter can be used as a base to create more useful servlet filters.  This request logging servlet filter and this redirection servlet filter serve as examples of viewing and modifying request data that the client sends to the web server.  In the future, I hope to provide an example of a data masking servlet filter that works on the response data that the web server generates for the client.