API-Debugging-Tools: Die sechs Registerkarten, die ich öffne, wenn ein Endpunkt für mich liegt

Ein Lizenzaktivierungsendpunkt für eines meiner Laravel-Projekte begann, jedes Token abzulehnen, das ihm übergeben wurde. Nicht einige Token. Jeder Token, einschließlich eines Tokens, der neunzig Sekunden zuvor ausgegeben hatte. Die Protokolle sagten token expireddrohen Die Token waren nicht abgelaufen. Ich verbrachte den größten Teil eines Samstags davon überzeugt, dass die Uhr auf der Box getrieben war.

es hatte nicht. Der Fehler war eine Zeile:

if (payload.exp < Date.now()) throw new Error('token expired')

exp in einem JWT ist Sekunde Da die Epoche - RFC 7519 §4.1.4 ist dies eindeutig. Date.now() In Javascript-Rück Millisekundendrohen Ich habe also eine zehnstellige Zahl mit einer dreizehnstelligen Zahl verglichen, und zehnstellige Zahlen sind immer kleiner. Jeder Token im Universum war für immer abgelaufen. Die Lösung war Date.now() / 1000drohen Die Diagnose dauerte acht Stunden, weil ich eigentlich nie schau Am Token - Ich habe meinen eigenen Code immer wieder gelesen, der das Debugging-Äquivalent der Suche nach Ihrer Brille beim Tragen ist.

Was schließlich die Schleife durchbrach, war das Einfügen des Tokens in einen Decoder, der las exp: 1748952000, Konvertieren Sie das in ein Datum und sehen Sie einen Zeitstempel in zwei Wochen in der Zukunft. Der Token war in Ordnung. Mein Vergleich war falsch. Dreißig Sekunden des Betrachtens von Daten schlagen acht Stunden des Betrachtens von Code.

Darum geht es in diesem Leitfaden. Nicht clevere Debugging-Philosophie - Die spezifischen, langweiligen, unglamourösen Browser-Tools, die ich in einer Registerkartengruppe namens "API-Debug" aufbewahre, und die Fehlermodi, die sie fangen. Alles hier läuft clientseitig toolz.dev, was wichtiger ist als es klingt, wenn es sich um einen Produktionsträger handelt, wenn das, was Sie einfügen möchten, ein Produktionsträger ist.

tl; dr: Wenn sich eine API schlecht benimmt, lesen Sie Ihren Code nicht mehr und beginnen Sie mit dem Lesen der Nutzlast. Formatieren Sie die Antwort mit JSON-Formaterdrohen Knacken Sie den Token mit dem JWT-Decoder, kein generisches Base64-Tool. Kurve exp, iat, und X-RateLimit-Reset in reale Daten mit dem Zeitstempelkonverterdrohen Vergleichen Sie eine Arbeitsantwort mit einer kaputten mit der Textdiff Oder besser, die json diffdrohen Dekodieren Sie die Query-String-Verstümmelung mit dem URL-Endrohen Alles läuft in Ihrem Browser - der Token geht nie über den Draht.

Warum fühlt sich das Debuggen einer API so viel schlimmer an als das Debuggen von Code?

Weil Sie es nicht durchgehen können. Ein lokaler Fehler hat eine Stack-Trace, einen Debugger und einen Haltepunkt. Ein API-Fehler hat eine Zeichenfolge. Jemand anderes Server hat diese Zeichenfolge nach Regeln erstellt, die Sie nur zur Hälfte kennen, und Ihre Aufgabe ist es, rückwärts davon zu arbeiten.

Das kehrt die übliche Fähigkeit um. Der Engpass ist nicht logisch, es ist Lesbarkeitdrohen Fast jeder API-Fehler, den ich in den letzten Jahren verfolgt habe, war unsichtbar, bis ich die Daten lesbar machte:

• Eine minimierte JSON-Antwort mit 4.000 Zeichen, die sich als "data": null in der Tiefe sechs begraben.
• Eine Base64-Nutzlast, die zu einer Fehlermeldung dekodiert wurde, war zu höflich, um den Statuscode einzugeben.
• Ein Webhook, bei dem die Signaturüberprüfung fehlgeschlagen ist, da der Text eine nachstehende Zeile mit einem HTTP-Client hinter sich hat, wurde hilfreich hinzugefügt.
• Ein Zeitstempel, der in Millisekunden war, als die Dokumente Sekunden sagten. (zweimal. verschiedene Unternehmen.)

Keines davon war harte Probleme. Alle waren schwer zu lesen Probleme. Die folgenden Tools sind vorhanden, um die Daten so schnell lesbar zu machen, dass Sie das, was Ihre Augen sonst überschieben würden, bemerken.

Welches Tool für welches Symptom?

Dies ist der Tisch, den ich mir wünschte, jemand hätte mir vor fünf Jahren gegeben. Symptom links, zuerst rechts bewegen.

Alles unten ist die lange Version dieser Tabelle.

Wie mache ich eine API-Antwort in zehn Sekunden lesbar?

kleben Sie es in die JSON-Formaterdrohen Das ist die ganze Technik, und ich bin nicht gleitfähig - die einzige Debugging-Gewohnheit, die ich habe, weigert sich, mich zu lehnen begründen Eine Nutzlast, die ich nicht formatiert habe.

Hier ist eine Antwortform, die ich von einem Abrechnungsanbieter bekomme, genau wie es vom Draht kommt:

{"subscriptions":[{"id":"sub_7f3d8a2b","status":"active","plan":{"id":"pro_annual","interval":"year","amount":9900},"current_period_end":1748952000,"cancel_at_period_end":false}],"has_more":false}

formatiert ist es ein ganz anderes Objekt - nicht für den Parser, sondern für mich:

{
  "subscriptions": [
    {
      "id": "sub_7f3d8a2b",
      "status": "active",
      "plan": {
        "id": "pro_annual",
        "interval": "year",
        "amount": 9900
      },
      "current_period_end": 1748952000,
      "cancel_at_period_end": false
    }
  ],
  "has_more": false
}

Jetzt kann ich das sehen amount ist 9900 Und nicht 99.00 — Es sind Cents, was der häufigste Integrationsfehler bei Zahlungen ist – und das current_period_end ist eine zehnstellige Ganzzahl, was Sekunden bedeutet, was bedeutet, dass Sie es nicht übergeben new Date() Direkt.

Validierung fängt Ihre Augen auf

Die Formatierung validiert auch. Ein Parse-Fehler ist Information. Die Fehler, die tatsächlich in echten Nutzlasten auftreten:

• Nachkomma. Legal in JavaScript, illegal in JSON (gemäß RFC 8259). Handbearbeitete Geräte sind voll davon.
• Einzelzitate. JSON erfordert doppelte Anführungszeichen. str(dict) Ausgabe ist nicht JSON, egal wie sehr es aussieht.
• Nicht zitierte Schlüssel. Dieselbe Geschichte - das ist ein JavaScript-Objektliteral, nicht JSON.
• NaN / Infinitydrohen Einige Serialisierer geben sie aus. JSON hat keine solchen Literale.
• Eine Stückliste. eine UTF-8-Byte-Order-Marke vor { Wird ein strenger Parser ein Dokument ablehnen, das auf dem Bildschirm perfekt aussieht.

Wenn Ihr JSON gültig ist, aber die formen ist falsch, das ist ein anderes Werkzeug - siehe den Diff-Abschnitt unten.

Warum sollte man einen JWT-Decoder verwenden, anstatt nur base64-Dekodierung des Tokens?

Sie können ein JWT von Hand auf Base64-Dekodieren. Ich habe es jahrelang gemacht. Es ist eine schlechte Angewohnheit, und hier ist der Grund.

Ein JWT (RFC 7519) ist drei durch Punkte getrennte Blöcke: Header, Payload, Signatur. Jeder Block ist base64url, nicht Standard Base64 — RFC 4648 §5, das URL-sichere Alphabet, das swaps +→- und /→_ und lässt normalerweise die fallen = Polsterung. Füttere dies einem strengen Standard-Base64-Decoder und gibt dir entweder einen Fehler oder gibt dir stillschweigend Müllbytes. Die Handmethode bedeutet also, Punkte zu teilen, das Alphabet neu zu füllen und das Alphabet auszutauschen, und dann Raw JSON auf den Kopf zu stellen.

der JWT-Decoder Wenn das alles in einer Paste und - der Teil, der tatsächlich Zeit spart - die Ansprüche als Ansprüche darstellt. Die, die ich überprüfe, in der Reihenfolge:

• exp (Ablauf) und iat (Ausgegeben bei) - beide numerisch, d.h. Sekunde Seit 1970-01-01 UTC. Dies ist das Feld, das meinen Samstag gegessen hat.
• aud (Publikum) - Ein Token, das für Ihre Staging-API geprägt wurde, wird strukturell perfekt und von Prod abgelehnt.
• iss (Emittent) - Nach einer Identitätsanbieter-Migration ist dies das Feld, das sich leise geändert hat.
• alg im Header - wenn es heißt noneSie haben ein Sicherheitsproblem, kein Debugging-Problem.

Nehmen Sie den kanonischen Beispiel-Token, den jeder gesehen hat:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header: {"alg":"HS256","typ":"JWT"}drohen Nutzlast: {"sub":"1234567890","name":"John Doe","iat":1516239022}drohen und iat da ist 2018-01-18T01:30:22Z - Was Sie nur wissen, wenn Sie es über einen Zeitstempelkonverter ausführen, was der springende Punkt des nächsten Abschnitts ist.

das, was ein Decoder nicht tut

Dekodierung wird nicht überprüft. Jeder kann ein JWT dekodieren, die Nutzlast ist verschlüsselt, nicht verschlüsselt. Ein Decoder sagt Ihnen, was der Token Schadenersatz, niemals ob die Behauptung wahr ist. Die Signaturüberprüfung erfolgt auf Ihrem Server mit Ihrem Geheimnis, und kein Browser-Tool sollte jemals dieses Geheimnis übergeben werden. Behandeln Sie ein dekodiertes JWT so, wie Sie eine Formulareinreichung behandeln: als Behauptung eines Fremden.

Wie höre ich auf, Zeitstempel falsch zu bekommen?

Lernen Sie, die Ziffernzählung zu lesen. Dies ist die billigste Debug-Fähigkeit im gesamten Bereich und es dauert eine Minute, um zu lernen.

Zehn Ziffern bedeutet Sekunden. Dreizehn bedeutet Millisekunden. Date Konstruktor will Millisekunden; Unix, Python time.time(), go & # 39; s Unix(), PHP & # 39; time()und die meisten Apis & # 39; exp Felder sprechen Sekunden. Alles, was nach diesem Missverhältnis hinter diesem Missverhältnis liegt, ist Chaos.

Und das Chaos ist in eine Richtung laut und in der anderen still. zuführen Sekunde Zu einem Millisekunden-Parser und Sie erhalten 1970 - ein Fehler, der so offensichtlich ist, dass Sie ihn in einer Minute beheben. zuführen Millisekunden zu einem Sekunde Parser und du bekommst das Jahr 56122drohen Ich habe überprüft: 1708876200000, als Sekunden interpretiert, landet am 17. Februar im Jahr 56122. Das ist die Richtung, die leise versendet, denn nichts wirft - ein Abonnement läuft einfach nie aus und niemand merkt es für ein Viertel.

der Zeitstempelkonverter Es gibt Sie, damit Sie dies in einer Paste begleichen können, anstatt darüber zu streiten. einkleistern 1748952000, Lesen Sie das Datum, fahren Sie fort. kleben Sie die X-RateLimit-Reset Der Header, über den sich Ihre API beschwert, und stellen Sie fest, dass Sie vier Minuten warten müssen, nicht vier Stunden. Wenn der Zeitstempel naiv ist (nein Z, kein Offset) und Sie müssen darüber nachdenken, was es in einer anderen Region bedeutet, der Zeitzonenkonverter ist die Nachverfolgung.

Zwei weitere Zeitstempelfallen, die es wert sind, wissenswert zu sein

Das Problem 2038 ist real und veraltet. Ein signierter 32-Bit-Sekunden-Zähler überläuft bei 2147483647, das ist 2038-01-19T03:14:07Zdrohen Jedes System, das noch Zeit in einem signierten 32-Bit-INT speichert - und es gibt mehr davon in eingebetteten und älteren Datenbankspalten, als irgendjemand zugeben möchte - dann wird unterbrochen. Wenn Sie heute langlebige Verfallszeiten festlegen, können Sie dies bereits erreichen.

Naive Zeitstempel sind eine Lüge durch Auslassung. 2026-02-25T14:30:00 ohne Nachfolge Z Und nein +05:30 ist kein Moment in der Zeit, es ist ein Moment an einem nicht spezifizierten Ort. Ich behandle jede API, die naive Zeitstempel zurückgibt, als einen Fehlerbericht, der darauf wartet, eingereicht zu werden. Bevorzugen Sie RFC 3339 (2026-02-25T14:30:00Z), das das strenge, eindeutige Profil von ISO 8601 ist, das das Web tatsächlich verwendet.

Was mache ich, wenn "es gestern" funktioniert hat?

Diff es. Theoretisieren Sie nicht - diff es.

Erfassen Sie die Antwort aus der Arbeitsumgebung (oder graben Sie die letzte gute aus Ihren Protokollen) und die Antwort der defekten und stellen Sie sie nebeneinander. Neun Mal von zehn gibt es genau einen Unterschied und es starrt Sie innerhalb von fünf Sekunden an.

Für JSON greifen Sie nach dem json diff Vor dem Text diff. es analysiert beide Seiten und vergleicht Struktur, was bedeutet, dass neu geordnete Schlüssel und unterschiedliche Einrückungen nicht als Änderungen angezeigt werden - nur echte. Ein Textunterschied aus zwei JSON-Dokumenten, die ein Server in einer anderen Schlüsselreihenfolge serialisiert, leuchtet wie ein Weihnachtsbaum und sagt Ihnen nichts.

Für alles, was JSON ist - Header, Rohkörper, Konfigurationsdateien, curl Ausgabe — Verwenden Sie die Textdiffdrohen Seine Spezialität ist die Klasse der Veränderungen, die Ihre Augen physisch nicht fangen können: ein nachlaufender Raum, eine Registerkarte, die zu vier Feldern wurde, eine CRLF-Linie, die von einem Windows-Computer aus eingeschoben wurde, ein lockiges Zitat, das eine Dokumentationsseite durch eine gerade ersetzte, als Sie das Beispiel kopierten. Ich habe ein ganzes Stück darüber geschrieben Warum fehlgeschlagene Textvergleiche fehlschlagen, weil es mich einmal eine Support-Eskalation gekostet hat.

Warum kommen meine Abfrageparameter immer wieder defekt?

Weil die URL-Codierung drei oder vier subtil unterschiedliche Geschmacksrichtungen hat und jeder Stack ein anderer auswählt.

Die Klassiker, in grober Reihenfolge, wie oft sie mich gebissen haben:

• + gegen %20drohen in einer Abfragezeichenfolge, + historisch bedeutet ein Raum (die application/x-www-form-urlencoded Konvention). in einem Pfadsegment, + bedeutet wörtliches Plus. Also eine Base64-Signatur mit +, in eine Abfragezeichenfolge nicht codiert, wird mit Leerzeichen eingetroffen und die Signaturprüfung fehlgeschlagen. Dies ist wirklich böse, weil der Wert Aussehen Direkt in den Protokollen.
• Doppelkodierung. %2F wird %252F Weil zwei Ebenen Ihres Stapels beide hilfreich codiert haben. Das Symptom ist ein Parameter, der bei jedem Durchlaufen eines Proxys Prozentzeichen erhält.
• Ein roher & innerhalb eines Wertes. Teilt Ihren Parameter in zwei Teile. jetzt name=Ben & Jerry ist name=Ben Plus ein Mystery-Parameal namens Jerrydrohen

Fügen Sie die URL in die URL-En und dekodiere es. Wenn es einmal noch Prozent-Escapes zurücklässt, haben Sie Ihre doppelte Codierung gefunden. Das ist die ganze Diagnose.

Wie debuggt ich einen nicht verifizierenden Webhook?

Dies ist derjenige, der "Ich verstehe http" von "Ich war auf Abruf" trennt.

Fast jeder Webhook-Anbieter signiert die Nutzlast mit einem HMAC und setzt das Ergebnis in einen Header. Ihre Aufgabe ist es, den gleichen HMAC zu berechnen und zu vergleichen. Wenn es nicht übereinstimmt, ist die Signatur fast nie das Problem. Die Bytes sind das Problem. Sie hascht nicht, was sie hascht.

Die üblichen Verdächtigen:

1. Sie haben den geparst-und-re-serialisierten Körper gehasht. Ihr Framework hat das JSON in ein Objekt geparst, das Sie angerufen haben JSON.stringify() Darauf und jetzt unterscheidet sich die Schlüsselreihenfolge oder der Leerraum um ein Zeichen. Sie müssen das haschen nagend Anfragetext, Bytes wie erhalten. Im Express bedeutet dies, den Rohpuffer vorher zu erfassen express.json() kommt dazu; in Laravel bedeutet es $request->getContent(), nicht $request->all()drohen
2. Eine nachlaufende Newline. Einige Kunden fügen einen an. Der Anbieter hat es nicht getan.
3. Sie haschen die hex-codierte Zeichenfolge anstelle der rohen Bytes, oder Vergleich von Hex mit Base64.
4. Zeichensatz. Der Körper hat ein Multi-Byte-Zeichen und etwas auf dem Weg, das es transcodiert.

der Hash-Generator So isoliere ich das: Nehmen Sie die genaue Körperzeichenfolge, hashen Sie sie, vergleichen Sie sie mit dem, was mein Code für das produziert hat, was es produziert Überlegung war der gleiche Körper. Wenn sich diese beiden Hashes unterscheiden, sieht mein Code nicht die Bytes, die ich zu sehen glaube, und das Problem war überhaupt nie kryptografierend. (Auch wissens wert: Wenn ein Anbieter noch MD5- oder SHA-1-Signaturen anbietet, ist dies ein Signal über das Alter seiner Plattform. SHA-256 ist jetzt der Boden.)

Was lebt noch in der Debug-Tab-Gruppe?

Die Nebenbesetzung – weniger glamourös, verdient noch ihren Platz:

• UUID-Generator - für eine saubere X-Request-ID Bei jedem Testaufruf können Sie es anschließend über drei Service-Protokolle nachlesen. Wissenswertes, dass UUIDs eine Spezifikationsaktualisierung erhalten haben: RFC 9562 (2024) veraltete RFC 4122 und standardisiert uuidv7, die zeitlich geordnet ist und daher sehr freundlicher zu Ihrer Datenbank ist als zufällig V4. Wenn Sie heute ein ID-Schema für eine neue Tabelle auswählen, ist dies das, worüber Sie nachlesen können. Es gibt eine längere Aufschlüsselung der UUID-Versionen Wenn du es willst.
• Base64-Konverter - für Authorization: Basic Header (RFC 7617: Es ist base64(user:password), und ja, das ist die Kodierung, nicht die Sicherheit - TLS schützt es) und für die inline binären Blobs einige APIs in JSON-Feldern. Base64 kostet Sie ~33%-Overhead, weshalb eine "unerwartet große" Nutzlast oft nur eine Datei enthält. der Vollständige Base64-Anleitung Deckt die Unterscheidung base64url ab, die Menschen auf die Beine stellt.
• YAML-Validator - Weil die Hälfte meiner API-Fehler im letzten Jahr keine API-Fehler waren. Es handelte sich um einen Fehler mit zwei Leerzeichen in einer CI-Konfiguration, und der Endpunkt wurde überhaupt nie bereitgestellt. (Yaml hat jedoch einen schlimmeren Fehlermodus als ein defekter Build: gültiger YAML, der etwas bedeutet, das Sie nicht beabsichtigt hatten. ich schrieb auf wieso version: 1.10 wird 1.1 nachdem es mich einen Deploy gekostet hat.)
• Regex-Tester - Im Moment müssen Sie eine Anfrage-ID aus 900 Protokollzeilen mit einem Muster ziehen, von dem Sie nicht überzeugt sind.
• CSV-Betrachter — Für den Export-Endpunkt, dessen Ausgabe Sie zur Überprüfung der Sanity-Check benötigen, bevor jemand ihn in die Produktion importiert.

Ist es eigentlich wichtig, dass diese im Browser laufen?

Ja, und ich würde das sagen, selbst wenn ich die Seite nicht gebaut hätte.

Überlegen Sie, was Sie in ein Debugging-Tool einfügen. ein JWT - das ist ein Live-Beglaubigung bis es abläuft. Eine Produktions-API-Antwort, bei der es sich um Kundendaten handelt: Namen, E-Mails, Abonnementzustände. Ein Webhook-Body, der einen Zahlungsdatensatz enthalten kann. ein curl Befehl mit einem Authorization Header noch drin.

Bedenken Sie nun, dass ein serverseitiges Tool per Definition all das erhält. Nicht böswillig - nur architektonisch. Die Einfügen geht in eine HTTP-Anfrage, trifft das Backend eines anderen und landet in der Protokollierung, die sie gerade ausführen. Selbst ein sorgsam ehrlicher Operator befindet sich in einem Zugriffsprotokoll, das er nie führen wollte.

Die Tools auf toolz.dev erledigen die Arbeit in JavaScript in Ihrem Tab. Es wird nichts hochgeladen, weil es nirgendwo hochgeladen werden kann - das Parsen, die Dekodierung und das Hashing auf Ihrem Computer. Sie müssen auch nicht mein Wort dafür nehmen: Öffnen Sie DevTools, gehen Sie auf die Registerkarte Netzwerk, fügen Sie einen Token ein und achten Sie auf eine Anfrage, die niemals eingeht. Das ist eine zweiunddreißigste Prüfung, und Sie sollten es durchführen irgendein Werkzeug, in das Sie Geheimnisse einfügen, meine enthalten. ich schrieb auf So überprüfen Sie ein clientseitiges Tool ordnungsgemäß Aus genau diesem Grund.

Wenn Ihre Organisation mit personenbezogenen Daten der EU umgeht, ist dies nicht nur Hygiene - das Einfügen von Kundendaten in einen Server eines Drittanbieters ist eine Verarbeitungsaktivität mit allen implizierten DSGVO-Papieren. Client-seitige Tools gehen der Frage aus dem Weg, indem sie nie Prozessor werden.

Ein Workflow, der tatsächlich bleibt

Sechs Schritte, in der Reihenfolge, in der ich sie führe, wenn etwas in Flammen steht:

1. Erfassen Sie die Rohantwort. Ganzkörper, volle Überschriften, Statuscode. Nicht die Interpretation Ihrer App - die tatsächlichen Bytes. curl -i oder die Netzwerk-Registerkarte "als curl."
2. formatiere es. JSON-Formaterdrohen Schau dir an formen Bevor Sie sich die Werte ansehen. Ist das Feld, das Sie brauchen, überhaupt präsent?
3. Dekodieren Sie jede undurchsichtige Zeichenfolge. Token durch die JWT-Decoder, Base64-Blobs durch die Base64-Konverter, verstümmelte URLs durch die URL-Endrohen Undurchsichtige Saiten verbergen die Antwort überraschend oft.
4. Verwandeln Sie jede Zahl, die eine Zeit sein könnte, in ein Datum. Zeitstempelkonverterdrohen Zählen Sie zuerst die Ziffern.
5. diff gegen eine bekannte-gute Antwort. json diffdrohen Wenn Sie keine bekannt-gute Antwort haben, ist dies Ihr Zeichen, um sie zu speichern.
6. Lesen Sie jetzt Ihren Code. An diesem Punkt kennen Sie normalerweise die Linie, bevor Sie die Datei öffnen.

Die Bestellung ist wichtig. In Schritt 6 habe ich früher angefangen, und deshalb hat dieser Samstag acht Stunden gedauert.

Häufig gestellte Fragen

Was sind die besten kostenlosen Tools für das Debuggen von APIs?

Für das tägliche API-Debugging benötigen Sie fünf Dinge: einen JSON-Formater und einen Validator, einen JWT-Decoder, einen Unix-Zeitstempelkonverter, ein Diff-Tool und einen URL-Encoder / Decoder. Alle fünf sind auf toolz.dev kostenlos und laufen komplett im Browser. Fügen Sie einen Hash-Generator hinzu, wenn Sie mit signierten Webhooks arbeiten, und einen YAML-Validator, wenn Ihre Bereitstellungen konfiguriert sind.

Ist es sicher, eine JWT- oder API-Antwort in ein Online-Tool einzufügen?

Nur wenn das Tool clientseitig ist. Ein JWT ist ein Live-Anmeldeinformationen und eine API-Antwort ist normalerweise Kundendaten. Ein serverseitiges Tool bedeutet daher, beide an das Backend eines Fremden zu versenden. Die Tools von toolz.dev verarbeiten alles in Ihrem Browser mit Javascript und senden nichts über das Netzwerk – überprüfen Sie dies selbst, indem Sie die Registerkarte „Network“ des DevTools beim Einfügen öffnen. Führen Sie die gleiche Überprüfung für jedes Tool aus, das Sie mit sensiblen Daten verwenden.

Warum sagt mein JWT "Abgelaufen" als ich es gerade generiert habe?

Die häufigste Ursache ist eine Fehlanpassung der Einheiten. der exp Der Anspruch ist in Sekunden (RFC 7519 definiert ihn als numerisches Datum), aber JavaScript Date.now() Gibt Millisekunden zurück, so dass jeder Token direkt verglichen wird. Dekodieren Sie den Token, lesen Sie exp, konvertieren Sie es mit einem Zeitstempelkonverter in ein echtes Datum und überprüfen Sie, ob es tatsächlich in der Vergangenheit liegt, bevor Sie Ihren Auth-Code berühren.

Wie erkenne ich, ob ein Unix-Zeitstempel in Sekunden oder Millisekunden vorliegt?

Zählen Sie die Ziffern. Zehn Ziffern sind Sekunden, dreizehn Millisekunden, sechzehn Mikrosekunden. Wenn ein Datum 1970 herauskommt, fütterst du Sekunden an einen Millisekunden-Parser, wenn er im Jahr 56122 herauskommt, fütterst du Millisekunden an einen Sekunden-Parser. Der zweite Fehler ist gefährlicher, da nichts einen Fehler wirft.

Kann ich diese Tools zum Debuggen von GraphQL-APIs verwenden?

Ja. GraphQL-Antworten sind JSON, also funktionieren der JSON-Formater und der JSON-Diff unverändert, und GraphQL verwendet normalerweise dieselbe Authentifizierung mit dem Träger-Token, die Sie mit dem JWT-Decoder dekodieren. Der einzige wirkliche Unterschied besteht darin, dass GraphQL HTTP 200 mit einem zurückgibt errors Array anstelle eines Nicht-2xx-Status, also immer den Körper formatieren - der Fehler liegt innerhalb der Nutzlast, nicht im Statuscode.

Warum schlägt meine Webhook-Signaturüberprüfung immer fehl?

Fast immer, weil Sie andere Bytes als der Anbieter haben. Wenn Ihr Framework den JSON-Körper analysiert und Sie ihn vor dem Hashing neu serialisiert hat, hat sich der Leerraum oder die Schlüsselreihenfolge geändert und der HMAC wird niemals übereinstimmen. Hash den RAW-Anforderungstext genau wie erhalten und prüfe eine nachstehende Zeile, die von deinem HTTP-Client hinzugefügt wurde.

Was ist der Unterschied zwischen Base64 und Base64URL-Codierung?

Standard Base64 (RFC 4648 §4) verwendet + und / In seinem Alphabet und Pads mit =drohen base64url (RFC 4648 §5) ersetzt diejenigen mit - und _ und lässt die Polsterung normalerweise fallen, damit der Wert sicher in eine URL oder ein JWT eingefügt wird. Das Feing von base64url-Daten an einen strengen Standard-Base64-Decoder erzeugt einen Fehler oder Müll, weshalb ein dedizierter JWT-Decoder die Handdecodierung eines Tokens übertrifft.

Wie debuggt ich eine 401 nicht autorisierte Antwort?

Arbeite aus dem Token nach außen. Dekodieren und überprüfen exp Gegen die aktuelle Zeit - ein abgelaufener Token ist die häufigste Ursache und unsichtbar, bis Sie den Anspruch in ein lesbares Datum konvertieren. Wenn der Token live ist, überprüfen Sie die Authorization Header selbst: Das Schema muss vorhanden und korrekt geschrieben sein (Bearer <token>, ein Leerzeichen, keine Anführungszeichen) und ein von einem Terminal eingefügter Token trägt oft eine nachstehende Zeile, die das Match unterbricht. Bestätigen Sie danach die aud und iss Ansprüche stimmen mit den Erwartungen der API überein, da ein gültiger Token, der für ein anderes Publikum ausgegeben wird, genau wie ein schlechtes abgelehnt wird. Erst dann fangen Sie an, den Server zu vermuten.

Wie dekodiere ich ein JWT ohne Bibliothek?

Ein JWT besteht aus drei Base64URL-Segmenten, die durch Punkte verbunden sind. Auf den Punkten aufteilen, dann base64url-dekodieren die ersten beiden - den Header und die Nutzlast - und beide werden als einfaches JSON herausgegeben. Das dritte Segment ist die Signatur und dekodiert nicht in etwas lesbares, da es eher rohe Bytes als Text sind. Dies ist wichtiger als es klingt: Die Dekodierung eines Tokens sagt Ihnen, was es behauptet, nicht ob diese Behauptungen wahr sind. Die Überprüfung der Signatur erfordert den Schlüssel des Emittenten und gehört in Ihren Servercode, niemals in einem Browser-Tool. Lesen Sie hier Tokens, um sie zu debuggen und in der Anwendung zu validieren.

Brauche ich noch Postbote oder Schlaflosigkeit, wenn ich diese Tools benutze?

Ja - sie lösen verschiedene Probleme. Ein API-Client sendet Anfragen, diese Tools machen die Antworten lesbar. In der Praxis verwende ich den Client, um die Anfrage auszulösen und die Rohausgabe zu kopieren und dann zu den Browser-Tools zu wechseln, um sie zu formatieren, zu dekodieren, zu konvertieren und zu diffieren. Sie sitzen nebeneinander im Workflow, anstatt sich gegenseitig zu ersetzen.