So testen Sie externe APIs in Elixir mit Bypass

API Pentesting for Vulnerability & Bug bounty | Authorization Token | Rate limit bypass | Test cases

API Pentesting for Vulnerability & Bug bounty | Authorization Token | Rate limit bypass | Test cases

Inhaltsverzeichnis:

Anonim

Wir priorisieren serviceorientierte Architekturprinzipien bei Inverse. Das heißt, wir haben kleine, wartbare Komponenten mit klar definierten Verantwortlichkeiten. Sie kommunizieren (meistens) über Representational State Transfer- oder REST-APIs miteinander.

Dies bietet Flexibilität und hat uns mit Ausnahme einer wichtigen Facette gut getan: Testen. Beim Testen sollte man vermeiden:

  • Abhängigkeit von externen Diensten, die auf demselben Computer ausgeführt werden.
  • Langsame Tests.

Da Anwendungen von Natur aus auf externe Dienste angewiesen sind, ist es wichtig, eine Teststrategie für diese Abhängigkeiten zu haben.

Wir haben vor kurzem mit Bypass angefangen und ich werde erklären, wie wir dorthin gekommen sind und insbesondere wie wir es verwenden.

Die Vergangenheit

Mock-Methoden und geben einige Beispieldaten wie folgt zurück:

Das war (und ich glaube immer noch) der Weg in die Welt von Ruby / Rails. Leider führt dies zu einem schlechten Verhalten, wie es José Valim am besten erklärt.

Wir haben dann angefangen, ExVCR zu verwenden, eine großartige Bibliothek, die aber ähnliche Nachteile wie Mocks / Stubs hat: Sie fördert Faulheit und fördert nicht die Trennung von Bedenken, die für klar definierte APIs von entscheidender Bedeutung sind. ExVCR ermöglicht die Aufzeichnung und Wiedergabe von Echtzeitdaten. Es ist sehr einfach zu integrieren (einschließlich einiger Zeilen in Ihrem Test und alles andere wird erledigt). Aber im Idealfall müssen Sie in Tests über externe Abhängigkeiten nachdenken, nicht sie abstrahieren. Es ist möglicherweise immer noch eine praktikable Wahl für Szenarien, in denen das Verhalten des Endpunkts mit minimalem Aufwand getestet werden sollte (wir verwenden es zum Testen von Aufrufen von AWS Services von Amazon wie S3).

Geben Sie die Adapter ein

Adapter arbeiten hervorragend und fördern die Prüfung von API-Verträgen und klar definierten Kommunikationsgrenzen. Wir verwenden diesen Ansatz immer noch, insbesondere wenn der Adapter komplexer ist (wie ein JSON-RPC-Socket).

So könnte ein Adapter aussehen:

Für einfache HTTP-Endpunkte scheinen Adapter jedoch eine Menge Arbeit zu sein und haben einen großen Nachteil: Sie lassen die Bibliotheken, die sie verbrauchen, aus der Testgleichung heraus. Wenn sich etwas in den HTTP- oder JSON-Bibliotheken ändert, werden sie durch die Tests nicht erfasst. Die Menge an produktionskritischem Code, die bei diesem Ansatz nicht getestet wurde, ist nicht akzeptabel.

Gegenwart und Zukunft

Mit Bypass können wir einen sehr einfachen Webserver in Tests starten, die die von uns verwendeten externen Dienste simulieren.

Jetzt können wir den gesamten Stack testen, einschließlich der HTTP-Bibliothek, der JSON-Codierung / Decodierungsbibliothek und der Authentifizierungsmechanismen. Das Bypass-README ist gut geschrieben, daher werde ich auf Details zur Implementierung verzichten. Wir ändern jedoch leicht, wie wir es verwenden, um die Tests kurz und lesbar zu halten:

Zunächst einmal möchten wir manchmal Facebook anrufen, wenn Tests als vollständige Integrationssuite ausgeführt werden. Wir tun dies unregelmäßig, um sicherzustellen, dass die Facebook-API weiterhin unseren Erwartungen entspricht. Hinzufügen - Integration einschließen zu Mix-Test simuliert nicht die API, sondern ruft den externen Dienst auf (Zeilen 5, 7).

Wir sind explizit, wenn wir Anfragen an externe Dienste simulieren, so dass jeder Test, der Bypass verwendet, über die Option verfügen muss @tag facebook_bypass (Zeile 7).

Endlich, das handle_fb Funktion (Zeilen 30–39) wird aufgerufen (vorausgesetzt, dass die Anforderungspfad Streichhölzer). Ich mag den Abgleich im Funktionskopf, da er explizit macht, auf welchen Pfad wir reagieren, und es uns ermöglicht, verschiedene Funktionen für verschiedene Pfade zu definieren.

Bypass läuft also nur mit getaggten Tests @tag: Bypass und wenn wir unsere Integrationssuite nicht ausführen. Eine weitere Sache, die wir beim Einrichten von Bypass ausführen, besteht darin, dass das Tag eine Seiten-ID übergeben kann (Zeilen 8, 20). So sieht ein Test, der Bypass verwendet, in seiner ganzen Pracht aus:

Wie Sie sehen können, die facebook_bypass tag macht deutlich, dass wir die API simulieren (es sei denn, wir befinden uns im Integrationsmodus). Es ermöglicht uns, Informationen an die simulierte API zu übergeben, und es ist sehr einfach, dieselbe Bypass-Konfiguration für verschiedene Tests wiederzuverwenden.

Ich hoffe, dies hilft Ihnen beim Testen externer APIs. Sie finden mich auf Twitter (siehe unten), wenn Sie weitere Fragen haben.