Direct tracking code injection to extension
Before we get started, it's important to understand what a tracking code is and why it is used.
When a user installs your extension, we need a way to identify the user to affiliate when they activate cash back through your extension, in order to attribute them properly when the sale completes its lifecycle. This is done at Wildfire by attaching a tc query parameter at the end of your affiliate url. Once the sale completes it's lifecycle, you can retrieve the value within the tc parameter. By going in to the admin tool, and posting the data to your callback url.
Example of a vanity url with a tc parameter:
Example of an offline vanity url with a tc parameter:
Many extensions use different models, whether it's an OAuth flow, or logging in directly through the extension. They all serve the purpose of having the user identify themselves, and saving that identifier in the extension's storage. This way is different because it doesn't require us making an http request within the extension after authenticating, and not storing any secrets in the extension when not needed.
Final things to note before we get started:
- The identifiers in the example urls are uuids, your platform may have different ways of identifying a user, the premise is the same.
- This method is only known to work in Chrome and Firefox. Safari does not allow the onMessageExternalmethod to be exposed for extensions.
- During this tutorial we will assume you have some knowledge of how chrome extensions work. Please check the documentation for basic information on getting a chrome extension setup and how they work.
- We will be using the v2 manifest version in the examples.
- The example code will contain a directory depicting an example web page that is ran locally on your computer. You can run a web server from VSCode using the Live Server extension. You can access the example code at the bottom of this document
- In the example extension we depict that the user is logged in based off whether or not the tracking code is stored within the extension. This behavior is common amongst our cash back extensions, primarily because we don't want the user activating cash back if we have no way of identifying who the user is.
With that out of the way let's get started. Take a look at the directory structure of the example code:
The extension directory contains the extension code, the website directory contains the code for your website. Your structure may look different.
Update your manifest.json with the following:
- Specify your web page as an externally_connectable web page. This enables the extension to communicate with tabs that have urls that match the matches property.
- Add a key in your manifest json to create a permanent extension ID. This ID will be used to communicate from your web page to your extension. For information on how to generate your own key see here. The extension ID in our example is aokkbecooohkgppimfffkongjlpihbol.
The "https://*.yoursite.com/*" value is there as a placeholder for you to enter you own url. The [<http://127.0.0.1:5500/*>](<http://127.0.0.1:5500/*>) is there for testing. We will be running our webpage through live server via vscode, you may be using something like web pack dev server or another local server. If you are using something else, make sure to update the port number in your manifest.json.
We can now move to the extension code. This is our background.js file.
The onMessageExternal listener dispatches an event when an outside entity communicates with the extension. We have the PING message to send back true to let the webpage know that we are able to communicate. The SET_TRACKING_CODE message is there for us to save the tracking code within the extension. In our example we are saving it in memory, but you will more than likely saving it to browser storage.
The onMessage listener dispatches an event when the content script or the popup script sends a message to background script. The IS_LOGGED_IN message is there to validate whether or not the extension has a tracking code in memory.
This is our popup.js file.
When the popup is rendered, we check and see if the tracking code has been stored in the background. The idea behind this behavior is that we don't want our user using our extension without first identifying themselves through our webpage.
Let's move to our webpage and fire it up using Live Server. This file is website/index.html.
If your button and input fields are greyed out, then you did not set your key properly. You can change the extensionID on line 8 of the website/main.js file
Here is said file:
This file does the following
- On initial load it checks to see if the chrome api is accessible. If your chrome api is not accessible you may be on the wrong browser.
- Selects the Input and Button elements for use later
- Fires off an immediately invoked function. We wrap in an IFFE here to be able to stop the execution of the rest of the code
- We send a ping to the extension to make sure we can communicate with it first. If we can't then the input and button remain disabled. If we are able to communicate with the extension, then we enable the input and button. Then we add an event listener on the button for you to send the tracking code to the extension side.
You can incorporate this logic into your own web pages. When to send the message is up to you, but it is probably best to do so when the user first logs in through your web page or first lands on your page if returning in a logged in state. This saves us the hassle of creating an OAuth login flow and saves you the danger of exposing secrets in your extension code.