Axios-Projekt mit 77,9 K GitHub-Repository: Welche Dinge sind es wert, gelernt zu werden?

Vorwort

Axios ist ein Promise-basierter HTTP-Client, der sowohl Browser als auch Node.js-Umgebungen unterstützt. Es ist ein ausgezeichneter HTTP-Client und wird in zahlreichen Webprojekten häufig verwendet.

Wie aus der obigen Abbildung ersichtlich ist, beträgt die Anzahl der Sterne des Axios-Projekts „77,9 K“ und die Anzahl der Forks beträgt „7,3 K“. Es handelt sich um ein sehr hervorragendes Open-Source-Projekt. Als Nächstes wird Abao Sie daher mitnehmen, um einige Aspekte des Axios-Projekts zu analysieren, von denen es sich zu lernen lohnt.

Nach der Lektüre dieses Artikels wissen Sie Folgendes:

• Entwurf und Implementierung eines HTTP-Interceptors;
• Entwurf und Implementierung eines HTTP-Adapters;
• So verteidigen Sie sich gegen CSRF-Angriffe.
  

Beginnen wir mit dem Einfachsten und lernen zunächst Axios kennen.

1. Einführung in Axios

Axios ist ein Promise-basierter HTTP-Client mit den folgenden Funktionen:

• Unterstützt Promise API;
• Möglichkeit, Anfragen und Antworten abzufangen;
• Möglichkeit zur Transformation von Anforderungs- und Antwortdaten;
• Der Client unterstützt die Abwehr von CSRF-Angriffen;
• Unterstützt sowohl Browser- als auch Node.js-Umgebungen;
• Möglichkeit zum Abbrechen von Anfragen und automatischen Konvertieren von JSON-Daten.
  

Browserseitig unterstützt Axios die meisten gängigen Browser wie Chrome, Firefox, Safari und IE 11. Darüber hinaus verfügt Axios auch über ein eigenes Ökosystem:

(Datenquelle – https://github.com/axios/axios/blob/master/ECOSYSTEM.md)

Nachdem wir Axios kurz vorgestellt haben, analysieren wir nun eine der Kernfunktionen, die es bietet – den Interceptor.

2. Entwurf und Implementierung eines HTTP-Interceptors

2.1 Interceptor-Einführung

Bei den meisten SPA-Anwendungen werden zur Authentifizierung von Benutzern normalerweise Token verwendet. Dies erfordert, dass wir nach der Authentifizierung in jeder Anforderung Authentifizierungsinformationen mitführen müssen. Um diese Anforderung zu erfüllen und zu vermeiden, dass jede Anfrage einzeln verarbeitet werden muss, können wir eine einheitliche Anfragefunktion kapseln, um jeder Anfrage Token-Informationen hinzuzufügen.

Wenn wir jedoch später eine Cache-Zeit für einige GET-Anfragen festlegen oder die Aufrufhäufigkeit einiger Anfragen steuern müssen, müssen wir die Anfragefunktion ständig ändern, um die entsprechenden Funktionen zu erweitern. Wenn wir an diesem Punkt eine einheitliche Antwortverarbeitung in Betracht ziehen, wird unsere Anforderungsfunktion immer größer und schwieriger zu verwalten. Wie lässt sich dieses Problem also lösen? Axios bietet uns eine Lösung – Interceptor.

Axios ist ein Promise-basierter HTTP-Client und das HTTP-Protokoll basiert auf Anfragen und Antworten:

Daher bietet Axios Anforderungs- und Antwort-Interceptors zur Verarbeitung von Anforderungen bzw. Antworten. Ihre Funktionen sind wie folgt:

• Anforderungs-Interceptor: Die Funktion dieses Interceptor-Typs besteht darin, vor dem Senden der Anforderung bestimmte Vorgänge einheitlich auszuführen, z. B. das Hinzufügen eines Token-Felds zum Anforderungsheader.
• Antwort-Interceptor: Die Funktion dieses Interceptor-Typs besteht darin, nach dem Empfang der Serverantwort bestimmte Vorgänge einheitlich auszuführen. Wenn der Antwortstatuscode beispielsweise 401 lautet, wird automatisch zur Anmeldeseite gesprungen.
  

Das Einrichten von Interceptors in Axios ist sehr einfach. Über die von den Objekten axios.interceptors.request und axios.interceptors.response bereitgestellte Methode use können Sie Request-Interceptors bzw. Response-Interceptors festlegen:

// Anfrage-Interceptor hinzufügen axios.interceptors.request.use(function (config) {
  config.headers.token = 'vom Interceptor hinzugefügt';
  Konfiguration zurückgeben;
});

// Antwort-Interceptor hinzufügen axios.interceptors.response.use(function (data) {
  data.data = data.data + '-modifiziert durch Interceptor';
  Daten zurückgeben;
});

Wie funktionieren Abfangjäger? Bevor wir uns den spezifischen Code ansehen, analysieren wir zunächst seine Designideen. Axios wird zum Senden von HTTP-Anfragen verwendet, und das Wesentliche von Anforderungs-Interceptoren und Antwort-Interceptoren ist eine Funktion, die eine bestimmte Funktion implementiert.

Wir können das Senden von HTTP-Anfragen entsprechend ihrer Funktion in verschiedene Arten von Unteraufgaben aufteilen, z. B. Unteraufgaben zum Verarbeiten von Anforderungskonfigurationsobjekten, Unteraufgaben zum Senden von HTTP-Anfragen und Unteraufgaben zum Verarbeiten von Antwortobjekten. Wenn wir diese Unteraufgaben in der angegebenen Reihenfolge ausführen, können wir eine vollständige HTTP-Anfrage abschließen.

Nachdem wir diese verstanden haben, werden wir die Implementierung des Axios-Interceptors unter drei Gesichtspunkten analysieren: Aufgabenregistrierung, Aufgabenplanung und Aufgabenplanung.

2.2 Aufgabenregistrierung

Durch die vorherigen Beispiele zur Verwendung von Interceptors wissen wir bereits, wie Anforderungs-Interceptors und Antwort-Interceptors registriert werden, wobei Anforderungs-Interceptors zum Verarbeiten von Unteraufgaben von Anforderungskonfigurationsobjekten verwendet werden, während Antwort-Interceptors zum Verarbeiten von Unteraufgaben von Antwortobjekten verwendet werden. Um zu verstehen, wie Aufgaben registriert werden, müssen Sie sich mit den Objekten Axios und Axios.interceptors auskennen.

// lib/axios.js
Funktion Instanzerstellung(Standardkonfiguration) {
  var Kontext = neuer Axios(Standardkonfiguration);
  var Instanz = binden(Axios.prototype.request, Kontext);

  // Kopiere axios.prototype in die Instanz
  utils.extend(Instanz, Axios.prototype, Kontext);
  // Kontext in Instanz kopieren
  utils.extend(Instanz, Kontext);
  Instanz zurückgeben;
}

//Erstellen der zu exportierenden Standardinstanz
var axios = Instanz erstellen(Standardwerte);

Im Quellcode von Axios haben wir die Definition des Axios-Objekts gefunden. Offensichtlich wird die Standardinstanz von Axios durch die Methode createInstance erstellt, die letztendlich das Funktionsobjekt Axios.prototype.request zurückgibt. Gleichzeitig haben wir den Konstruktor von Axios gefunden:

// lib/core/Axios.js
Funktion Axios(Instanzkonfiguration) {
  this.defaults = Instanzkonfiguration;
  diese.interceptors = {
    Anfrage: neuer InterceptorManager(),
    Antwort: neuer InterceptorManager()
  };
}

Im Konstruktor fanden wir die Definition des Objekts axios.interceptors und wussten auch, dass sowohl das Objekt interceptors.request als auch das Objekt interceptors.response Instanzen der Klasse InterceptorManager sind. Daher wird eine weitere Analyse des InterceptorManager-Konstruktors und der zugehörigen Verwendungsmethoden zeigen, wie die Aufgabe registriert wird:

// lib/core/InterceptorManager.js
Funktion InterceptorManager() {
  diese.handler = [];
}

InterceptorManager.prototype.use = Funktion use(erfüllt, abgelehnt) {
  dies.handlers.push({
    erfüllt: erfüllt,
    abgelehnt: abgelehnt
  });
  // Gibt den aktuellen Index zurück, der zum Entfernen des registrierten Interceptors verwendet wird. return this.handlers.length - 1;
};

Durch Beobachten der Use-Methode können wir sehen, dass die registrierten Interceptors in der Handler-Eigenschaft des InterceptorManager-Objekts gespeichert werden. Nachfolgend verwenden wir ein Diagramm, um die interne Struktur und Beziehung zwischen dem Axios-Objekt und dem InterceptorManager-Objekt zusammenzufassen:

2.3 Aufgabenplanung

Jetzt wissen wir, wie man Interceptor-Aufgaben registriert, aber das Registrieren von Aufgaben reicht nicht aus. Wir müssen die registrierten Aufgaben auch planen, um die Ausführungsreihenfolge der Aufgaben sicherzustellen. Hier unterteilen wir die Ausführung einer vollständigen HTTP-Anforderung in drei Phasen: Verarbeiten des Anforderungskonfigurationsobjekts, Initiieren der HTTP-Anforderung und Verarbeiten des Antwortobjekts.

Schauen wir uns als Nächstes an, wie Axios eine Anfrage sendet:

axios({
  URL: '/hallo',
  Methode: 'get',
}).dann(res =>{
  console.log('axios res: ', res)
  console.log('axios res.data: ', res.data)
})

Durch die vorherige Analyse wissen wir bereits, dass das Axios-Objekt dem Funktionsobjekt Axios.prototype.request entspricht. Die spezifische Implementierung dieser Funktion lautet wie folgt:

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

  // Etwas Code weglassen var chain = [dispatchRequest, undefined];
  var promise = Promise.resolve(Konfiguration);

  // Aufgabenplanung this.interceptors.request.forEach(function unshiftRequestInterceptors(interceptor) {
    Kette.unshift(Abfangjäger.erfüllt, Abfangjäger.abgelehnt);
  });

  this.interceptors.response.forEach(Funktion pushResponseInterceptors(Interceptor) {
    Kette.Push(Abfangjäger.erfüllt, Abfangjäger.abgelehnt);
  });

  // Aufgabenplanung während (Kettenlänge) {
    Versprechen = Versprechen.dann(Kette.Shift(), Kette.Shift());
  }

  Rückgabeversprechen;
};

Der Code für die Aufgabenplanung ist relativ einfach. Werfen wir einen Blick auf die Vergleichstabelle vor und nach der Aufgabenplanung:

2.4 Aufgabenplanung

Nachdem die Aufgabenplanung abgeschlossen ist, müssen wir zum Initiieren einer HTTP-Anforderung auch die Aufgabenplanung in der geplanten Reihenfolge ausführen. Die spezifische Versandmethode in Axios ist sehr einfach, wie unten gezeigt:

 // lib/core/Axios.js
Axios.prototype.request = Funktion request(config) {
  // Etwas Code weglassen var promise = Promise.resolve(config);
  während (Kettenlänge) {
    Versprechen = Versprechen.dann(Kette.Shift(), Kette.Shift());
  }
}

Da die Kette ein Array ist, können wir die festgelegten Aufgaben kontinuierlich über die while-Anweisung herausnehmen und sie dann zu einer Promise-Aufrufkette zusammenstellen, um die Aufgabenplanung zu implementieren. Der entsprechende Verarbeitungsablauf ist in der folgenden Abbildung dargestellt:

Lassen Sie uns den vollständigen Verwendungsprozess des Axios-Interceptors überprüfen:

// Anforderungs-Interceptor hinzufügen - Anforderungskonfigurationsobjekt verarbeiten axios.interceptors.request.use(function (config) {
  config.headers.token = 'vom Interceptor hinzugefügt';
  Konfiguration zurückgeben;
});

// Antwort-Interceptor hinzufügen - Antwortobjekt verarbeiten axios.interceptors.response.use(function (data) {
  data.data = data.data + '-modifiziert durch Interceptor';
  Daten zurückgeben;
});

axios({
  URL: '/hallo',
  Methode: 'get',
}).dann(res =>{
  console.log('axios res.data: ', res.data)
})

Nachdem wir den Interceptor von Axios vorgestellt haben, fassen wir nun seine Vorteile zusammen. Axios bietet einen Interceptor-Mechanismus, der es Entwicklern ermöglicht, unterschiedliche Verarbeitungslogiken im Anforderungslebenszyklus einfach anzupassen.

Darüber hinaus kann die Funktionalität von Axios auch durch den Interceptor-Mechanismus flexibel erweitert werden, wie beispielsweise durch die beiden im Axios-Ökosystem aufgeführten Bibliotheken axios-response-logger und axios-debug-log.

Aus dem Entwurfsmodell des Axios-Interceptors können wir das folgende allgemeine Aufgabenverarbeitungsmodell extrahieren:

3. Entwurf und Implementierung des HTTP-Adapters

3.1 Standard-HTTP-Adapter

Axios unterstützt sowohl Browser- als auch Node.js-Umgebungen. Für die Browserumgebung können wir HTTP-Anfragen über XMLHttpRequest oder Fetch API senden, und für die Node.js-Umgebung können wir HTTP-Anfragen über die integrierten http- oder https-Module von Node.js senden.

Zur Unterstützung verschiedener Umgebungen führt Axios Adapter ein. Im Abschnitt zum Entwurf des HTTP-Interceptors haben wir eine Methode dispatchRequest gesehen, die zum Senden von HTTP-Anfragen verwendet wird. Ihre spezifische Implementierung ist wie folgt:

// lib/core/dispatchRequest.js
module.exports = Funktion dispatchRequest(config) {
  // Etwas Code weglassen var adapter = config.adapter || defaults.adapter;
  
  returniere Adapter(Konfiguration).dann(Funktion beiAdapterAuflösung(Antwort) {
    // Einen Teil des Codes weglassen, um die Antwort zurückzugeben;
  }, Funktion beiAdapterAblehnung(Grund) {
    // Etwas Code weglassen return Promise.reject(reason);
  });
};

Wenn wir uns die Methode dispatchRequest oben ansehen, können wir erkennen, dass Axios benutzerdefinierte Adapter unterstützt und auch einen Standardadapter bereitstellt. Für die meisten Szenarien benötigen wir keinen benutzerdefinierten Adapter, sondern können direkt den Standardadapter verwenden. Daher enthält der Standardadapter den Anpassungscode für den Browser und die Node.js-Umgebung. Die spezifische Anpassungslogik lautet wie folgt:

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

Funktion getDefaultAdapter() {
  var-Adapter;
  wenn (Typ von XMLHttpRequest !== 'undefiniert') {
    // Für Browser den XHR-Adapter verwenden
    Adapter = erforderlich('./adapters/xhr');
  } sonst wenn (Typ des Prozesses !== 'undefiniert' && 
    Object.prototype.toString.call(Prozess) === '[Objekt Prozess]') {
    // Für Knoten HTTP-Adapter verwenden
    Adapter = erforderlich('./adapters/http');
  }
  Rücklaufadapter;
}

In der Methode getDefaultAdapter werden zunächst verschiedene Plattformen anhand bestimmter Objekte in der Plattform unterschieden und dann verschiedene Adapter importiert. Der spezifische Code ist relativ einfach und wird hier nicht vorgestellt.

3.2 Benutzerdefinierter Adapter

Tatsächlich können wir zusätzlich zum Standardadapter auch den Adapter anpassen. Wie passen Sie den Adapter an? Hier können wir auf das von Axios bereitgestellte Beispiel verweisen:

var settle = erfordern('./../core/settle');
module.exports = Funktion meinAdapter(Konfiguration) {
  // Aktueller Zeitpunkt:
  // - Das Konfigurationsobjekt wurde mit der Standardanforderungskonfiguration zusammengeführt // - Der Anforderungskonverter wurde ausgeführt // - Der Anforderungs-Interceptor wurde ausgeführt // Stellen Sie eine Anforderung mit dem bereitgestellten Konfigurationsobjekt // Behandeln Sie den Status von Promise basierend auf dem Antwortobjekt return new Promise(function(resolve, reject) {
    var Antwort = {
      Daten: Antwortdaten,
      Status: Anfrage.Status,
      statusText: Anfrage.statusText,
      Header: Antwortheader,
      Konfiguration: Konfiguration,
      Anfrage: Anfrage
    };

    regeln (lösen, ablehnen, antworten);

    // Danach:
    // - Antwortkonverter werden ausgeführt // - Antwort-Interceptors werden ausgeführt });
}

In den obigen Beispielen haben wir uns auf die Laufzeit von Konvertern, Interceptors und die grundlegenden Anforderungen von Adaptern konzentriert. Wenn beispielsweise ein benutzerdefinierter Adapter aufgerufen wird, muss ein Promise-Objekt zurückgegeben werden. Dies liegt daran, dass Axios intern Promise-Kettenaufrufe verwendet, um die Anforderungsplanung abzuschließen. Wenn Sie sich darüber nicht im Klaren sind, können Sie den Abschnitt „Entwurf und Implementierung von Interceptors“ erneut lesen.

Nachdem wir nun wissen, wie der Adapter angepasst wird, stellt sich die Frage, wofür benutzerdefinierte Adapter nützlich sind. Im Axios-Ökosystem entdeckte Abao die Bibliothek Axios-Mock-Adapter, mit der Entwickler Anfragen einfach über benutzerdefinierte Adapter simulieren können. Die entsprechenden Anwendungsbeispiele lauten wie folgt:

var axios = erfordern("axios");
var MockAdapter = erforderlich("axios-mock-adapter");

// Richten Sie den Mock-Adapter auf der Standard-Axios-Instanz ein. var mock = new MockAdapter(axios);

// GET /users-Anfrage simulieren mock.onGet("/users").reply(200, {
  Benutzer: [{ id: 1, name: "John Smith" }],
});

axios.get("/Benutzer").then(Funktion (Antwort) {
  Konsole.log(Antwort.Daten);
});

Freunde, die sich für MockAdapter interessieren, können sich über die Axios-Mock-Adapter-Bibliothek informieren. Bisher haben wir Axios-Interceptors und -Adapter vorgestellt. Hier ist ein Bild, das den Anforderungsverarbeitungsablauf zusammenfasst, nachdem Axios Anforderungs-Interceptors und Antwort-Interceptors verwendet hat:

4. CSRF-Abwehr

4.1 Einführung in CSRF

„Cross-Site Request Forgery“, oft als „CSRF“ oder „XSRF“ abgekürzt, ist eine Angriffsmethode, die einen Benutzer dazu zwingt, unbeabsichtigte Aktionen auf der aktuell angemeldeten Webanwendung auszuführen.

Vereinfacht ausgedrückt handelt es sich bei einem Cross-Site-Request-Angriff um einen Angriff, bei dem ein Angreifer technische Mittel einsetzt, um den Browser des Benutzers dazu zu bringen, eine vom Angreifer authentifizierte Website aufzurufen und dort bestimmte Vorgänge auszuführen (beispielsweise das Senden von E-Mails oder Nachrichten oder sogar Finanzvorgänge wie Geldüberweisungen und den Kauf von Waren). Da die Authentifizierung des Browsers erfolgt ist, geht die besuchte Website davon aus, dass es sich um eine echte Benutzeroperation handelt und führt diese aus.

Um Ihnen das Verständnis des obigen Inhalts zu erleichtern, hat Bruder Abao ein Beispieldiagramm eines Cross-Site-Request-Angriffs gezeichnet:

In der obigen Abbildung hat der Angreifer eine Schwachstelle bei der Benutzerauthentifizierung im Web ausgenutzt: „Eine einfache Authentifizierung kann nur sicherstellen, dass die Anfrage vom Browser eines bestimmten Benutzers gesendet wird, sie kann jedoch nicht sicherstellen, dass die Anfrage selbst freiwillig vom Benutzer gestellt wird.“ Angesichts der Existenz der oben genannten Schwachstellen stellt sich die Frage: Wie sollten wir uns schützen? Als nächstes stellen wir einige gängige CSRF-Abwehrmaßnahmen vor.

4.2 CSRF-Abwehrmaßnahmen

4.2.1 Überprüfen Sie das Referrer-Feld

Im HTTP-Header gibt es ein Referer-Feld, das verwendet wird, um die Adresse anzugeben, von der die Anfrage kommt. „Bei der Verarbeitung sensibler Datenanfragen sollte das Referrer-Feld grundsätzlich unter demselben Domänennamen liegen wie die angefragte Adresse.“

Am Beispiel des Einkaufszentrums sollte die Adresse im Referrer-Feld normalerweise die Webadresse des Einkaufszentrums sein, die sich auch unter www.semlinker.com befinden sollte. Wenn die Anfrage von einem CSRF-Angriff stammt, enthält das Referrer-Feld die Adresse einer bösartigen URL und befindet sich nicht unter www.semlinker.com. Zu diesem Zeitpunkt kann der Server bösartige Zugriffe identifizieren.

Dieses Verfahren ist einfach und leicht umzusetzen und erfordert lediglich einen zusätzlichen Prüfschritt an den wichtigsten Zugangspunkten. Dieser Ansatz hat jedoch auch seine Grenzen, da er vollständig darauf angewiesen ist, dass der Browser das richtige Referrer-Feld sendet. Obwohl das HTTP-Protokoll klare Bestimmungen für den Inhalt dieses Felds enthält, kann es weder die spezifische Implementierung des besuchenden Browsers garantieren, noch kann es garantieren, dass der Browser keine Sicherheitslücken aufweist, die dieses Feld betreffen. Es besteht auch die Möglichkeit, dass Angreifer bestimmte Browser angreifen und deren Referrer-Felder manipulieren.

4.2.2 Synchrone Formular-CSRF-Prüfung

CSRF-Angriffe sind erfolgreich, da der Server nicht zwischen normalen Anfragen und Angriffsanfragen unterscheiden kann. Um dieses Problem zu beheben, können wir verlangen, dass alle Benutzeranforderungen ein Token enthalten, das ein CSRF-Angreifer nicht erhalten kann. Für den Formularangriff im CSRF-Beispieldiagramm können wir die Abwehrmaßnahme „Synchronous Form CSRF Verification“ verwenden.

„Synchronisierte CSRF-Verifizierung des Formulars“ bedeutet, dass das Token beim Zurückkehren zur Seite auf der Seite gerendert wird und dass das CSRF-Token beim Absenden des Formulars über ein verstecktes Feld oder als Abfrageparameter an den Server gesendet wird. Wenn Sie beispielsweise eine Seite synchron rendern, fügen Sie der Formularanforderung einen _csrf-Abfrageparameter hinzu, damit das CSRF-Token übermittelt wird, wenn der Benutzer das Formular absendet:

<form method="POST" action="/upload?_csrf={{vom Server generiert}}" enctype="multipart/form-data">
  Benutzername: <input name="name" />
  Avatar auswählen: <input name="file" type="file" />
  <button type="submit">Senden</button>
</form>

4.2.3 Doppelte Cookie-Verteidigung

„Double Cookie Defense“ besteht darin, das Token im Cookie festzulegen, das Cookie beim Senden von Anforderungen wie (POST, PUT, PATCH, DELETE) zu senden und das im Cookie festgelegte Token durch den Anforderungsheader oder den Anforderungstext zu übertragen. Nachdem der Server die Anforderung empfangen hat, führt er einen Vergleich und eine Überprüfung durch.

Nehmen wir jQuery als Beispiel, um zu sehen, wie das CSRF-Token festgelegt wird:

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

Funktion csrfSafeMethod(Methode) {
  // Die folgenden HTTP-Methoden erfordern keinen CSRF-Schutz return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));
}

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

Nachdem wir die Methoden und Abwehrmaßnahmen gegen CSRF-Angriffe vorgestellt haben, schauen wir uns nun an, wie sich Axios gegen CSRF-Angriffe verteidigt.

4.3 Axios CSRF-Abwehr

Axios bietet zwei Eigenschaften, xsrfCookieName und xsrfHeaderName, um den CSRF-Cookienamen bzw. den HTTP-Anforderungsheadernamen festzulegen. Ihre Standardwerte sind wie folgt:

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

  // Etwas Code weglassen xsrfCookieName: 'XSRF-TOKEN',
  xsrfHeaderName: 'X-XSRF-TOKEN',
};

Wir haben bereits gewusst, dass Axios auf verschiedenen Plattformen unterschiedliche Adapter zum Senden von HTTP-Anfragen verwendet. Hier nehmen wir die Browserplattform als Beispiel, um zu sehen, wie Axios sich gegen CSRF-Angriffe verteidigt:

// lib/adapters/xhr.js
module.exports = Funktion xhrAdapter(config) {
  returniere neues Promise (Funktion dispatchXhrRequest(auflösen, ablehnen) {
    var requestHeaders = config.headers;
    
    var request = neue XMLHttpRequest();
    // Etwas Code weglassen // XSRF-Header hinzufügen if (utils.isStandardBrowserEnv()) {
      var xsrfValue = (config.withCredentials || isURLSameOrigin(fullPath)) und config.xsrfCookieName?
        cookies.lesen(config.xsrfCookieName) :
        undefiniert;

      wenn (xsrfWert) {
        requestHeaders[config.xsrfHeaderName] = xsrfWert;
      }
    }

    Anfrage.Senden(AnfrageDaten);
  });
};

Nachdem Sie den obigen Code gelesen haben, kennen Sie die Antwort vermutlich bereits. Es stellt sich heraus, dass Axios die Lösung „Double Cookie Defense“ verwendet, um sich gegen CSRF-Angriffe zu verteidigen.

Okay, der Hauptinhalt dieses Artikels wurde hier vorgestellt. Tatsächlich gibt es im Axios-Projekt noch einige Dinge, von denen es sich zu lernen lohnt, wie z. B. das Design von CancelToken und den Ausnahmebehandlungsmechanismus. Interessierte Freunde können sich selbst darüber informieren.

5. Referenzressourcen

• Github - Axios
• Wikipedia - Cross-Site-Request-Forgery
• Egg - Prävention von Sicherheitsbedrohungen durch CSRF

Zusammenfassen

Dies ist das Ende dieses Artikels darüber, was es aus dem 77,9K Axios-Projekt auf GitHub zu lernen gibt. Für eine detailliertere Analyse des Axios-Projekts suchen Sie bitte nach früheren Artikeln auf 123WORDPRESS.COM oder stöbern Sie weiter in den verwandten Artikeln unten. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!