Analytics JavaScript Injection using an F5 BIG-IP iRule Part 2
Scenario
A line of business web application (we shall again refer to it here as ExpensiveApp1) is currently delivered via the F5 BIG-IP and there is a business need to evaluate the performance of the application in the company offices across the world. As before, this would normally be a simple task of adding the JavaScript used by the analytics software but the suppliers of ExpensiveApp1 are highly reluctant to allow any changes to be made to the servers on which the application runs. You have now configured the F5 to successfully inject the analytics JavaScript when it is reported that the analytics data for ExpensiveApp1 shows that a particular page is showing up constantly in the reports.
Solution
After a bit of analysis using Fiddler you determine that a background refresh is occurring due to the use, or some might say misuse, of the following meta tag : <meta http-equiv="refresh" content="25">.
As the page is refreshed constantly at 25 second intervals, the analytics reporting is, as you might expect, skewed. It would of course be possible to use the F5 and a stream profile to excise the, long since deprecated, meta tag but, again, we shall assume that the tag has some purpose and will therefore opt to avoid injecting the Webtuna JavaScript into that page instead. In the interests of clarity, the offending meta tag was actually on its own page and was called from code. There are, it would seem, things in life that you just cannot polish.
The Updated IRule
when HTTP_REQUEST {
# Disable the stream filter for client requests
STREAM::disable
if {[URI::decode [HTTP::uri]] starts_with "/keepViewAlive" }
{
# set variable to indicate that it is ExpensiveApp1 background refresh page
set stupid_app 1
return
}
else
{
set stupid_app 0
return
}
}
when HTTP_RESPONSE {
# Disable the stream filter for server responses
STREAM::disable
# Enable the stream filter for text responses only and for pages without the meta tag
if {([HTTP::header value Content-Type] contains "text") and ($stupid_app eq 0)}{
# Inject the code to load the JavaScript
STREAM::expression {@</title>@</title><script type="text/javascript" src="http:// goodapp1.mycompany.local /js/webtuna.js"></script>@}
# Enable the stream filter for this response only
STREAM::enable
}
}
Notes
The easiest way to avoid injecting the JavaScript on to the offending page was to capture the request to the URL as the URL is only available in a HTTP_REQUEST and set a variable to 1 if it is the offending page. In the HTTP_RESPONSE, all that is then needed is to add a check using that variable to ensure we are on some other page used by ExpensiveApp1 and inject the JavaScript as normal.