Utilo

Calculateur de signatures HTTP

Calculez et déboguez pas à pas les signatures de requêtes API : AWS Signature V4, Alibaba Cloud ACS3, Tencent Cloud TC3-HMAC-SHA256 et OAuth 1.0a, et vérifiez les signatures de webhooks GitHub, Stripe et Slack — localement avec Web Crypto.

Ce que fait cette calculatrice de signature HTTP

"La signature de demande que nous avons calculée ne correspond pas à la signature que vous avez fournie" est l'une des erreurs les plus frustrantes dans le travail d'API, parce que le serveur ne vous dit jamais quelle étape a mal tourné. Cette calculatrice reproduit l'ensemble du processus de signature pour AWS Signature Version 4, Alibaba Cloud ACS3-HMAC-SHA256, Tencent Cloud TC3-HMAC-SHA256 et OAuth 1.0a HMAC-SHA1, et montre chaque valeur intermédiaire: la requête canonique, son hachage, la chaîne à signer, la clé de signature dérivée et la signature finale et les en-têtes. Il vérifie également les signatures webhook entrant de GitHub, Stripe et Slack. Toute la cryptographie utilise l'API Web Crypto du navigateur, donc vos clés secrètes restent sur votre appareil.

Mode d'emploi

  1. Choisissez le fournisseur.
  2. Entrez la méthode, l'URL, les en-têtes (un Name: value par ligne) et le corps exactement comme votre code les envoie.
  3. Indiquer la clé d'accès, la clé secrète et, le cas échéant, la région et le service. Cliquez sur Utiliser l'heure actuelle ou pincer un horodatage fixe pour comparer avec une demande capturée.
  4. Comparez chaque étape avec ce que votre SDK ou votre code enregistre. La première étape qui diffère, c'est où se trouve votre insecte.
  5. Pour les webhooks, collez le corps de la demande brute octet par octet, l'en-tête de signature et votre secret de signature, et l'outil vous indique si elle correspond.

Causes courantes de déséquilibre des signatures

  • Codification URI canonique: AWS code chaque segment de chemin; S3 ne code pas en double.
  • Ordonnance des requêtes: les paramètres doivent être triés par clé codée, et les valeurs vides ont toujours besoin de =.
  • En-têtes signés: Les noms des en-têtes sont en minuscules, découpés, triés et joints à ;. Oublier host ou x-amz-date est courant.
  • Hash de charge utile: S3 nécessite l'en-tête x-amz-content-sha256; d'autres services hashent simplement le corps.
  • Séquilibre horaire: la plupart des fournisseurs rejettent les demandes de plus de 515 minutes.
  • Webhooks: Les frameworks analysent et ré-sérialisent souvent JSON avant de le voir. Vérifiez contre les octets bruts, pas un objet recodé. La bande signe timestamp.body, le Slack signe v0:timestamp:body.

Questions fréquentes

C'est sûr de saisir ma clé secrète ?

La page effectue tous les calculs localement avec Web Crypto et n'envoie rien. Pour les secrets de production, préférez des identifiants temporaires ou une clé de test de toute façon.

La mise en œuvre d'AWS a-t-elle été testée?
  • Je suis désolé. Il reproduit les signatures d'exemple de la documentation AWS Signature Version 4, qui font partie des tests automatisés du site.
Prend-il en charge AWS SigV4A ou les URL prédésignées ?
  • Pas encore. SigV4 basé sur l'en-tête est pris en charge; la signature de chaîne de requêtes prédéfinie est sur la feuille de route.
Pourquoi OAuth 1.0a a besoin de mes paramètres corporels ?

Pour les corps codés sous forme, les paramètres font partie de la chaîne de base de la signature. Les corps JSON ne sont pas inclus.

Oui. Tout le traitement s'effectue directement dans votre navigateur grâce à JavaScript, aux Web Workers et aux API Web. Rien de ce que vous saisissez, collez ou importez n'est envoyé à nos serveurs.

Cette page a été traduite automatiquement depuis l'anglais. Si vous repérez une erreur, dites-le-nous.