Local jQuery Setup in Splunk

Splunk recently made the following change to their AppInspect recommendations regarding jQuery libraries:

Assess your jQuery dependencies in the packaged libraries and if any file uses jQuery libraries from the internal Splunk library. Best practice going forward is to package all of your app’s dependencies in the app itself.

Note: The following is only applicable if your app is using jQuery in JavaScript files that you are loading into Splunk dashboards.

The question then becomes: How do I load in my own version of jQuery? 

Loading in your version

Fortunately, the solution not terribly complicated–but it is also not terribly obvious, so in this blog post (and corresponding screencast below), I will cover how to do two things:

  1. Load in a local version of jQuery
  2. Override the global version of jQuery with your local version

My install of Splunk is version 8.0.3 which comes with jQuery version 2.1.0, so I will be loading in a local version 3.6.0 of jQuery just for demonstration purposes.

Set your app up

First, find an app where you’d like to replace the global version of Splunk’s jQuery with your own.

It’s assumed that if your app is using JavaScript it will already have the ‘appserver’ folder as well as it’s child folder ‘static’.

Within the ‘static’ I created a ‘lib’ folder:

Copy to Clipboard

It’s assumed your other JavaScript files are in the appserver/static directory.

Get the jQuery source code

The first thing you want to do is head on over to

Copy the highlighted portion above and paste it into your browser URL bar. Then copy the code.

Go back into your app and inside of the lib folder we recently created create a new file called jquery-3.6.0.min.js and then paste in the code you copied.

Define a module for the local jQuery version

Inside of the lib directory where you added in the jQuery source code, create a new file called localJquery.js.

Inside of this file we will be defining a reusable module for our local jQuery. This will make it easy to update our version of jQuery in one place if needed in the future.

Inside of the localJquery.js file add the following:

Copy to Clipboard

The above will hook into Splunk’s global Require.js configuration and allow us to load in our local version of jQuery.

The shim acts as a way for the module to know what the value of our local instance will be so that when we pass the value into the module, it doesn’t throw an undefined error.

Copy to Clipboard

Then we want to set up our module using define(), which is just special syntax used by Require.js to define a reusable module. We then want to load in our jqueryLocal, which is passed into our function parameter as $.

We then return $.noConflict(true), so that our version of jQuery won’t conflict with the global version.

And that’s it for our module. Go ahead and save the file.

Load the local version of jQuery

Find a JavaScript file where you are using Splunk’s jQuery and open it up.

Once inside of that file, add the following at the top:

Copy to Clipboard

Then, depending on if you are simply using a require() or define() component, it essentially works the same:

Require Component Example

Copy to Clipboard

Define Component Example

Copy to Clipboard

Once you’ve loaded in localJquery, then you can set the value of $ to your local jQuery instance, which is helpful if you are already calling $() throughout your JavaScript file.

Copy to Clipboard

Once you do that, you will need to clear Splunk’s static caching by going to:


Click the Bump button on the above page, which will increment the number. Then go to the dashboard where you are loading in your JavaScript and open up your browser’s console window. You should see that the jQuery version number has changed to 3.6.0.

And that’s it! 


Going from 2.1.0 to 3.6.0 is a major jump, so thoroughly test your code to ensure it still works as expected.

If you run into any issues, feel free to reach out on Twitter @hurricanelabs.

The post Local jQuery Setup in Splunk appeared first on Hurricane Labs.

*** This is a Security Bloggers Network syndicated blog from Hurricane Labs authored by Ian Gillespie. Read the original post at: