Calculate an Interval Between TimeStamps
This post shows how to use Date, Time, Intervals, and Timestamps to determine if the EGL application has been launched within the past five minutes using only the hours, minutes and seconds provided as an encoded parameter on the URL. Using the HHMMSS, a full timestamp object is created containing the current date. Using an Interval, a determination can be made about how far in the past the timestamp lies as compared to a timestamp that represents the current date and time.
Without access to LDAP services that can be used to authenticate a user, alternate methods are employed to prevent users from bookmarking a web page that can be used later. The scheme chosen for this purpose relies upon encoding of the time at which the menu option was selected to launch the application. At that point the time (HHMMSS) is encrypted, encoded as a parameter and integrated within the URL string that directs the browser to the web page.
When the EGL application starts it obtains the full URL string (using document.location), isolates the parameter representing the HHMMSS, decrypts it and then performs the EGL date calculations presented below to determine if this is a “fresh” invocation of the application as opposed to a “stale” request as a consequence of using a bookmark.
Validate the Parameters
The task of isolating the parameters from the URL has been performed. The parameters are passed in an array and it is the second parameter that contains the HHMMSS that is the focus of the function presented below.
The first task to perform is to decrypt the parameters. This is performed using a PCML based call to the RPG program residing on the local iSeries. The HHMMSS is then decrypted from “TVWXTY” into a human readable “145617”. Now, EGL can use this as the basis for a timestamp object.
Fig.1 – Source code for the validate function
This section of the function decrypts the parameters passed on the URL. The HHMMSS to be decrypted is contained in the variable named ‘hhmmssEncrypted’.
Fig.2 – Decrypting the URL parameters.
Now that the time parameter has been decrypted, the first thing to do is to create a timestamp. To do this the time in HHMMSS is used to create a time object which is then used as the basis for a fully formed timestamp.
Next, another timestamp is created, based upon the current time. An interval object is created representing 5 minutes which is subtracted from the current time giving a new timestamp as of 5 minutes ago
The EGL code used to do this is isolated below.
Fig.3 – Creating urlTime from the decrypted HHMMSS.
This section of the function determines if the difference between the time passed on the URL is within the last 5 minutes of the present time. It does this by determining the difference between the timestamp of the HHMMSS on the URL and the timestamp for 5 minutes ago. The answer is placed into another interval of minutes called ‘differenceInMinutes’.
A test is made to see if that difference is within 5 minutes which is the range allowed to declare a URL request as “fresh”. The boolean for true is returned to the RichUI Handler’s start function which then allows processing to continue, i.e. the user did not use a bookmark to launch the application, they used the proper menu option on an internally controlled web page that is the launch point for all applications.
Fig.4 – Determining the time elapsed.
The values of each variable derived in the code above are shown in this variables list as seen in the IDE.
The values shown above where taken during testing of the function. Astute observers will note a very stale time has been supplied. Needles to say, the boolean returned is ‘false’. Also, the weakness of the scheme is also revealed in that a bookmarked URL will always be determined to be within 5 minutes of the current time for each day.
This scheme prevents launching of applications from bookmarks.