Follow

Considerations with Single Page Applications

This article is intended to go over a few scenarios to illustrate how caching, Force Identification (Force ID), Single Page Apps, and whitelisting can interact with each other. 

Assumptions

Below will be the workflow for the following scenarios:

Client --> CDN --> Legacy Distil Proxy --> Origin

All requests go to the URI https://www.foo.bar/login.html. The basic application has the browser send an AJAX request to POST credentials to the login endpoint /submit.json when attempting to authenticate. In all of the following examples, the setting Automated Browsers is set to CAPTCHA and Force Identification is set to enabled. It is important to consider that the behavior of Force ID can be different with Automated browser set to monitor vs CAPTCHA/Block/Drop. However, that is a topic for another article.

Scenario 1 

Further Assumptions

Caching enabled at CDN False
Some whitelisting is applied False

Above is the most straight forward example. All users from all locations will have the same experience. If the user's browser has not fingerprinted yet, then the client will go through the identification process. Below is the Force identification process.

The browser sends a GET /login.html without having fingerprinted or setting the Distil identifiers within an existing session. Instead of Distil proxying the request to the origin Distil will perform the following:

  1. Distil will return the identification page
  2. The browser will fingerprint
  3. The browser will be directed to /distil_identify_cookie.html
  4. The browser will be redirected via a 302 to URI that the client originally requested. From this example, the URI would be /login.html

Once the user's browser has successfully gone through the above workflow, the client will be able to submit credentials via AJAX to /submit.json with Distil cookies.

Scenario 2

Further Assumptions

Caching enabled at CDN True
Some whitelisting is applied False

In this example, different users can have different experiences when interacting with the website. We will assume that the origin returns cacheable content and that the CDN honors cache control headers and directives. The first user to the site will go through the identification process mentioned in scenario 1. However, when the 2nd user visits the site shortly after the 1st user, the 2nd user will see the cached version of the of /login.html resource. The /login.html page should still have the Distil JS injected into the page so that the 2nd user may fingerprint properly. As long as the 2nd user is able to execute the Distil JS prior to sending the AJAX call to /submit.json, then the user workflow will not be disrupted. However, if the 2nd user submits their credentials to the endpoint /submit.json prior to completing the Distil fingerprinting process, then this will result in a violation. Distil recommends to key on the browser load event to disable the site login event until the load event has completed. Below a link to the browser load event.

 https://developer.mozilla.org/en-US/docs/Web/API/Window/load_event

Scenario 3

Further Assumptions

Caching enabled at CDN True
Some whitelisting is applied True

This example will be similar to scenario 2 as long as the 1st user does not have the requests to /login.html whitelisted. However, if requests to /login.html are whitelisted for the 1st user and not the 2nd, then the experience for the 2nd user will be different.

If the whitelisted version of the resource is cached for /login.html, then the Distil JS will not be injected in the response HTML. This means that while the 2nd user will be able fetch the resource /login.html from the CDN cache, the browser will not be able to fingerprint. When the 2nd user attempts to authenticate to /submit.json, the 2nd user will not have a unique session and will receive a captcha response.

 

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments