Jump logging and stats-gathering

4
Average: 4 (1 vote)

Portal access data is gathered at different stages during a Jump session. Data is recorded when a user logs in, as well as when a user changes tabs, or logs out. This data is used to provide information to network security staff, to help map portal usage trends and to help the Jump team determine what channels are popular and how they are used.

To reduce the impact on the user, the system uses Asynchronous Javascript and XML (AJAX) to communicate with the server. This allows the browser to report on the state of the user’s session without an additional call to the server and without interrupting the user’s Jump session.

Components

Browser

When the body.onload() or body.onunload() event fires, a javascript function communicates (using AJAX) with a Java Server Page on the Jump server. The function sends a JSON object to the target JSP which details tab and channel usage.

JSON (Javascript object notation) is a simple way to model an object graph with a serializable string. (At time of writing, the recording of channels and tabs is still under development).

Back end

Jump employs custom code to render user-defined skins and colours as well as to remove channels to which the user is not authorized. The code that assembles pages as per user-specified skin and colour also collects information on the tab being displayed, as well as all the channels being displayed on that tab. It writes these to a javascript variable in JSON format.

Upon receipt of the AJAX call, the JSP examines the HttpSession, and uses the org.jasig.portal.security.provider.SimplePersonManager class to determine details about the logged-in user. The JSP employs com.pipeline.web.WebUtil to expose the HttpSession object to the JSP. It is employed in this fashion:

if (WebUtil.sessionOkay(request, response)) {
	// data stored in a Jump session is available here
	...
} else {
	// this block is called when the JSP is called from without a valid Jump session.
	...
}

The Session provides data from the HTTP header and the SimplePersonManager provides access to the Person object associated with the Jump session.

Another back-end component is the Servlet that handles the AJAX request from the AccessLogViewerChannel. In order for the servlet to be available to requests, an entry must be set up in the web.xml file.

Channel

Security needed a tool to examine Jump sessions, so we built a channel for them that provides a printable spreadsheet view of access, searchable either by ID or IP. Like many of our admin-tool class of channels, it uses AJAX and XHTML to provide an easy way to browse and print reports. Also, the channel employs an LGPL-licensed javascript calendar widget to provide a calendar interface for choosing dates.

Data

Data is stored in three tables.
• One table tracks JSESSIONID, username, IP address, user-agent data and timestamps of first and last recorded action.
• Another table stores JSESSIONID and role information.
• A third table stores JSESSIONID, tab name and channel id

Oracle Procedures employ the MERGE INTO function to perform “upserts” when writing session data to the database. When a JSESSIONID is unique, this function performs an insert, but when the JSESSIONID is found to exist already, the function performs an update.

Reporting

Jump usage statistics are available on the web. A nightly cron job runs a script that gathers information from the recording tables for reporting. All reporting is broken down by the roles Student, Faculty, Employee and Guest as well as a report for all users together.
Data is reported on session length, time of day user counts, total logins and distinct logins. Usage is reported by hour, day, month and year.

the attachments

  • sql*.zip - This file contains the sql to create tables and packages
  • java*.zip - this file contains java code for the channel and the servlet
  • mark*.jsp.txt - this file is the target JSP file
  • um_calendar_widget*.zip - this file contains the javascript calendar widget