Axios project with 77.9K GitHub repository: What are the things worth learning?

Preface

Axios is a Promise-based HTTP client that supports both browsers and Node.js environments. It is an excellent HTTP client and is widely used in a large number of Web projects.

As can be seen from the above figure, the number of stars of the Axios project is "77.9K", and the number of forks is as high as "7.3K". It is a very excellent open source project, so next Abao will take you to analyze some of the aspects of the Axios project that are worth learning from.

After reading this article, you will know the following:

• Design and implementation of HTTP interceptor;
• Design and implementation of HTTP adapter;
• How to defend against CSRF attacks.
  

Let's start with the simplest and learn about Axios first.

1. Introduction to Axios

Axios is a Promise-based HTTP client with the following features:

• Support Promise API;
• Ability to intercept requests and responses;
• Ability to transform request and response data;
• The client supports defense against CSRF attacks;
• Supports both browser and Node.js environments;
• Ability to cancel requests and automatically convert JSON data.
  

On the browser side, Axios supports most major browsers, such as Chrome, Firefox, Safari, and IE 11. In addition, Axios also has its own ecosystem:

(Data source - https://github.com/axios/axios/blob/master/ECOSYSTEM.md)

After briefly introducing Axios, let's analyze one of the core functions it provides - interceptor.

2. Design and implementation of HTTP interceptor

2.1 Interceptor Introduction

For most SPA applications, tokens are usually used to authenticate users. This requires that after authentication is passed, we need to carry authentication information in each request. To meet this requirement, in order to avoid processing each request separately, we can encapsulate a unified request function to add token information to each request.

But later, if we need to set a cache time for some GET requests or control the calling frequency of some requests, we need to constantly modify the request function to expand the corresponding functions. At this point, if we consider unified response processing, our request function will become larger and larger and more difficult to maintain. So how to solve this problem? Axios provides us with a solution - interceptor.

Axios is a Promise-based HTTP client, and the HTTP protocol is based on requests and responses:

Therefore, Axios provides request interceptors and response interceptors to handle requests and responses respectively. Their functions are as follows:

• Request interceptor: The function of this type of interceptor is to perform certain operations uniformly before the request is sent, such as adding a token field to the request header.
• Response interceptor: The function of this type of interceptor is to uniformly perform certain operations after receiving the server response. For example, if the response status code is 401, it will automatically jump to the login page.
  

It is very simple to set up interceptors in Axios. Through the use method provided by the axios.interceptors.request and axios.interceptors.response objects, you can set request interceptors and response interceptors respectively:

// Add request interceptor axios.interceptors.request.use(function (config) {
  config.headers.token = 'added by interceptor';
  return config;
});

// Add response interceptor axios.interceptors.response.use(function (data) {
  data.data = data.data + '-modified by interceptor';
  return data;
});

So how do interceptors work? Before looking at the specific code, let's analyze its design ideas first. Axios is used to send HTTP requests, and the essence of request interceptors and response interceptors is a function that implements a specific function.

We can break down sending HTTP requests into different types of subtasks according to their functions, such as subtasks for processing request configuration objects, subtasks for sending HTTP requests, and subtasks for processing response objects. When we execute these subtasks in the specified order, we can complete a complete HTTP request.

After understanding these, we will analyze the implementation of Axios interceptor from three aspects: task registration, task scheduling and task scheduling.

2.2 Task Registration

Through the previous examples of using interceptors, we already know how to register request interceptors and response interceptors, where request interceptors are used to process subtasks of request configuration objects, while response interceptors are used to process subtasks of response objects. To understand how tasks are registered, you need to understand axios and axios.interceptors objects.

// lib/axios.js
function createInstance(defaultConfig) {
  var context = new Axios(defaultConfig);
  var instance = bind(Axios.prototype.request, context);

  // Copy axios.prototype to instance
  utils.extend(instance, Axios.prototype, context);
  // Copy context to instance
  utils.extend(instance, context);
  return instance;
}

// Create the default instance to be exported
var axios = createInstance(defaults);

In the source code of Axios, we found the definition of the axios object. Obviously, the default axios instance is created by the createInstance method, which ultimately returns the Axios.prototype.request function object. At the same time, we found the constructor of Axios:

// lib/core/Axios.js
function Axios(instanceConfig) {
  this.defaults = instanceConfig;
  this.interceptors = {
    request: new InterceptorManager(),
    response: new InterceptorManager()
  };
}

In the constructor, we found the definition of the axios.interceptors object, and we also knew that both interceptors.request and interceptors.response objects are instances of the InterceptorManager class. Therefore, further analysis of the InterceptorManager constructor and related use methods will show how the task is registered:

// lib/core/InterceptorManager.js
function InterceptorManager() {
  this.handlers = [];
}

InterceptorManager.prototype.use = function use(fulfilled, rejected) {
  this.handlers.push({
    fulfilled: fulfilled,
    rejected: rejected
  });
  // Returns the current index, used to remove the registered interceptor return this.handlers.length - 1;
};

By observing the use method, we can see that the registered interceptors will be saved in the handlers property of the InterceptorManager object. Below we use a diagram to summarize the internal structure and relationship between the Axios object and the InterceptorManager object:

2.3 Task Scheduling

Now we know how to register interceptor tasks, but registering tasks is not enough. We also need to schedule the registered tasks to ensure the execution order of the tasks. Here we divide the completion of a complete HTTP request into three stages: processing the request configuration object, initiating the HTTP request, and processing the response object.

Next, let's take a look at how Axios sends a request:

axios({
  url: '/hello',
  method: 'get',
}).then(res =>{
  console.log('axios res: ', res)
  console.log('axios res.data: ', res.data)
})

Through the previous analysis, we already know that the axios object corresponds to the Axios.prototype.request function object, the specific implementation of this function is as follows:

// lib/core/Axios.js
Axios.prototype.request = function request(config) {
  config = mergeConfig(this.defaults, config);

  // Omit some code var chain = [dispatchRequest, undefined];
  var promise = Promise.resolve(config);

  // Task scheduling this.interceptors.request.forEach(function unshiftRequestInterceptors(interceptor) {
    chain.unshift(interceptor.fulfilled, interceptor.rejected);
  });

  this.interceptors.response.forEach(function pushResponseInterceptors(interceptor) {
    chain.push(interceptor.fulfilled, interceptor.rejected);
  });

  // Task scheduling while (chain.length) {
    promise = promise.then(chain.shift(), chain.shift());
  }

  return promise;
};

The code for task scheduling is relatively simple. Let's take a look at the comparison chart before and after task scheduling:

2.4 Task Scheduling

After the task scheduling is completed, to initiate an HTTP request, we also need to execute the task scheduling in the scheduled order. The specific dispatch method in Axios is very simple, as shown below:

 // lib/core/Axios.js
Axios.prototype.request = function request(config) {
  // Omit some code var promise = Promise.resolve(config);
  while (chain.length) {
    promise = promise.then(chain.shift(), chain.shift());
  }
}

Because chain is an array, we can continuously take out the set tasks through the while statement, and then assemble them into a Promise call chain to implement task scheduling. The corresponding processing flow is shown in the figure below:

Let's review the complete usage process of Axios interceptor:

// Add request interceptor - process request configuration object axios.interceptors.request.use(function (config) {
  config.headers.token = 'added by interceptor';
  return config;
});

// Add response interceptor - process response object axios.interceptors.response.use(function (data) {
  data.data = data.data + '-modified by interceptor';
  return data;
});

axios({
  url: '/hello',
  method: 'get',
}).then(res =>{
  console.log('axios res.data: ', res.data)
})

After introducing Axios's interceptor, let's summarize its advantages. Axios provides an interceptor mechanism that allows developers to easily customize different processing logic in the request life cycle.

In addition, the functionality of Axios can also be flexibly extended through the interceptor mechanism, such as the two libraries axios-response-logger and axios-debug-log listed in the Axios ecosystem.

Referring to the design model of Axios interceptor, we can extract the following general task processing model:

3. Design and implementation of HTTP adapter

3.1 Default HTTP Adapter

Axios supports both browser and Node.js environments. For the browser environment, we can send HTTP requests through XMLHttpRequest or fetch API, and for the Node.js environment, we can send HTTP requests through the built-in http or https modules of Node.js.

To support different environments, Axios introduces adapters. In the HTTP interceptor design section, we saw a dispatchRequest method, which is used to send HTTP requests. Its specific implementation is as follows:

// lib/core/dispatchRequest.js
module.exports = function dispatchRequest(config) {
  // Omit some code var adapter = config.adapter || defaults.adapter;
  
  return adapter(config).then(function onAdapterResolution(response) {
    // Omit some code return response;
  }, function onAdapterRejection(reason) {
    // Omit some code return Promise.reject(reason);
  });
};

By looking at the dispatchRequest method above, we can see that Axios supports custom adapters and also provides a default adapter. For most scenarios, we do not need a custom adapter, but directly use the default adapter. Therefore, the default adapter will contain the adaptation code for the browser and Node.js environment. The specific adaptation logic is as follows:

// lib/defaults.js
var defaults = {
  adapter: getDefaultAdapter(),
  xsrfCookieName: 'XSRF-TOKEN',
  xsrfHeaderName: 'X-XSRF-TOKEN',
  //...
}

function getDefaultAdapter() {
  var adapter;
  if (typeof XMLHttpRequest !== 'undefined') {
    // For browsers use XHR adapter
    adapter = require('./adapters/xhr');
  } else if (typeof process !== 'undefined' && 
    Object.prototype.toString.call(process) === '[object process]') {
    // For node use HTTP adapter
    adapter = require('./adapters/http');
  }
  return adapter;
}

In the getDefaultAdapter method, different platforms are first distinguished by specific objects in the platform, and then different adapters are imported. The specific code is relatively simple and will not be introduced here.

3.2 Custom Adapter

In fact, in addition to the default adapter, we can also customize the adapter. So how do you customize the adapter? Here we can refer to the example provided by Axios:

var settle = require('./../core/settle');
module.exports = function myAdapter(config) {
  // Current timing:
  // - The config object has been merged with the default request configuration // - The request converter has been run // - The request interceptor has been run // Make a request using the provided config object // Handle the state of Promise based on the response object return new Promise(function(resolve, reject) {
    var response = {
      data: responseData,
      status: request.status,
      statusText: request.statusText,
      headers: responseHeaders,
      config: config,
      request: request
    };

    settle(resolve, reject, response);

    // After this:
    // - response converters will run // - response interceptors will run });
}

In the above examples, we focused on the runtime timing of converters, interceptors, and basic requirements of adapters. For example, when a custom adapter is called, a Promise object needs to be returned. This is because Axios internally uses Promise chain calls to complete request scheduling. If you are not clear about this, you can re-read the "Design and Implementation of Interceptors" section.

Now that we know how to customize the adapter, what are custom adapters useful for? In the Axios ecosystem, Abao discovered the axios-mock-adapter library, which allows developers to easily simulate requests through custom adapters. The corresponding usage examples are as follows:

var axios = require("axios");
var MockAdapter = require("axios-mock-adapter");

// Set up the mock adapter on the default Axios instance var mock = new MockAdapter(axios);

// Simulate GET /users request mock.onGet("/users").reply(200, {
  users: [{ id: 1, name: "John Smith" }],
});

axios.get("/users").then(function (response) {
  console.log(response.data);
});

Friends who are interested in MockAdapter can learn about the axios-mock-adapter library. So far we have introduced Axios interceptors and adapters. Here is a picture to summarize the request processing flow after Axios uses request interceptors and response interceptors:

4. CSRF Defense

4.1 Introduction to CSRF

"Cross-site request forgery", often abbreviated as "CSRF" or "XSRF", is an attack method that forces a user to perform unintended actions on the currently logged-in web application.

To put it simply, a cross-site request attack is when an attacker uses some technical means to trick the user's browser into visiting a website that the attacker has authenticated and performing some operations (such as sending emails, messages, or even financial operations such as transferring money and purchasing goods). Since the browser has been authenticated, the visited website will assume that it is a genuine user operation and run it.

In order to help you better understand the above content, Brother Abao drew an example diagram of a cross-site request attack:

In the above figure, the attacker exploited a vulnerability in user authentication on the Web: "Simple authentication can only ensure that the request is sent from a certain user's browser, but it cannot ensure that the request itself is voluntarily issued by the user." Since the above vulnerabilities exist, how should we defend ourselves? Next we will introduce some common CSRF defense measures.

4.2 CSRF Defense Measures

4.2.1 Check the Referer field

There is a Referer field in the HTTP header, which is used to indicate the address from which the request comes. "When processing sensitive data requests, generally speaking, the Referer field should be located under the same domain name as the requested address."

Taking the mall operation in the example, the Referer field address should usually be the web address of the mall, which should also be located under www.semlinker.com. If the request is from a CSRF attack, the Referer field will contain the address of a malicious URL and will not be located below www.semlinker.com. At this time, the server can identify malicious access.

This method is simple and easy to implement, and only requires an additional check step at key access points. But this approach also has its limitations, because it completely relies on the browser to send the correct Referer field. Although the HTTP protocol has clear provisions for the content of this field, it cannot guarantee the specific implementation of the visiting browser, nor can it guarantee that the browser has no security vulnerabilities that affect this field. There is also the possibility that attackers can attack certain browsers and tamper with their Referer fields.

4.2.2 Synchronous form CSRF check

CSRF attacks are successful because the server cannot distinguish between normal requests and attack requests. To address this issue, we can require that all user requests carry a token that a CSRF attacker cannot obtain. For the form attack in the CSRF example diagram, we can use the "Synchronous Form CSRF Verification" defense measure.

"Synchronous form CSRF verification" means rendering the token on the page when returning the page, and submitting the CSRF token to the server through a hidden field or as a query parameter when the form is submitted. For example, when rendering a page synchronously, add a _csrf query parameter to the form request so that the CSRF token is submitted when the user submits the form:

<form method="POST" action="/upload?_csrf={{generated by the server}}" enctype="multipart/form-data">
  Username: <input name="name" />
  Select avatar: <input name="file" type="file" />
  <button type="submit">Submit</button>
</form>

4.2.3 Double Cookie Defense

"Double Cookie Defense" is to set the token in the cookie, submit the cookie when submitting requests such as (POST, PUT, PATCH, DELETE), and carry the token set in the cookie through the request header or request body. After the server receives the request, it will perform a comparison and verification.

Let's take jQuery as an example to see how to set the CSRF token:

let csrfToken = Cookies.get('csrfToken');

function csrfSafeMethod(method) {
  // The following HTTP methods do not require CSRF protection return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));
}

$.ajaxSetup({
  beforeSend: function(xhr, settings) {
    if (!csrfSafeMethod(settings.type) && !this.crossDomain) {
      xhr.setRequestHeader('x-csrf-token', csrfToken);
    }
  },
});

After introducing the methods and defenses of CSRF attacks, let's take a look at how Axios defends against CSRF attacks.

4.3 Axios CSRF Defense

Axios provides two properties, xsrfCookieName and xsrfHeaderName, to set the CSRF cookie name and HTTP request header name respectively. Their default values ​​are as follows:

// lib/defaults.js
var defaults = {
  adapter: getDefaultAdapter(),

  // Omit some code xsrfCookieName: 'XSRF-TOKEN',
  xsrfHeaderName: 'X-XSRF-TOKEN',
};

We have already known that Axios uses different adapters to send HTTP requests on different platforms. Here we take the browser platform as an example to see how Axios defends against CSRF attacks:

// lib/adapters/xhr.js
module.exports = function xhrAdapter(config) {
  return new Promise(function dispatchXhrRequest(resolve, reject) {
    var requestHeaders = config.headers;
    
    var request = new XMLHttpRequest();
    // Omit some code // Add xsrf header if (utils.isStandardBrowserEnv()) {
      var xsrfValue = (config.withCredentials || isURLSameOrigin(fullPath)) && config.xsrfCookieName ?
        cookies.read(config.xsrfCookieName) :
        undefined;

      if (xsrfValue) {
        requestHeaders[config.xsrfHeaderName] = xsrfValue;
      }
    }

    request.send(requestData);
  });
};

After reading the above code, I believe you already know the answer. It turns out that Axios uses the "double cookie defense" solution to defend against CSRF attacks.

Okay, the main content of this article has been introduced here. In fact, there are still some things in the Axios project that are worth learning from, such as the design of CancelToken and the exception handling mechanism. Interested friends can learn about it by themselves.

5. Reference Resources

• Github - axios
• Wikipedia - Cross-site request forgery
• Egg - Security Threat CSRF Prevention

Summarize

This is the end of this article about what is worth learning from the 77.9K Axios project on GitHub. For more detailed analysis of the Axios project, please search for previous articles on 123WORDPRESS.COM or continue to browse the related articles below. I hope everyone will support 123WORDPRESS.COM in the future!