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.
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).
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.
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 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.
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.
Recent comments
45 min 59 sec ago
11 hours 21 min ago
13 hours 52 min ago
21 hours 23 min ago
1 day 4 hours ago
1 day 12 hours ago
1 day 12 hours ago
1 day 12 hours ago
1 day 15 hours ago
1 day 17 hours ago