J'essaie actuellement de développer une application pour télécharger des fichiers sur un godet Amazon S3 à l'aide de CURL et C ++. Après avoir listé attentivement le guide des développeurs S3, j'ai commencé à implémenter mon application à l'aide de CURL et à former l'en-tête tel que décrit par le Guide des développeurs et après de nombreux essais et erreurs pour déterminer le meilleur moyen de créer la signature S3, je suis maintenant confronté à une erreur 501 . L'en-tête reçu suggère que la méthode que j'utilise n'est pas mise en œuvre. Je ne suis pas sûr d'où je me trompe, mais voici l'en-tête HTTP que j'envoie à Amazon: J'ai tronqué le nom du godet, l'identifiant de clé d'accès et la signature pour des raisons de sécurité. Je ne suis pas sûr de ce que je fais mal mais je pense que l'erreur génère en raison des champs d'acceptation et de codage de transfert (pas vraiment sûr). Alors quelqu'un peut-il me dire ce que je fais mal ou pourquoi je reçois un 501?
3 Réponses :
résolu: il manquait un curlopt pour la taille du fichier dans mon code et tout fonctionne parfaitement
Quelle option? Comment les en-têtes ont-ils changé?
Je ne comprends jamais pourquoi les gens répondent avec des réponses dans le sens de "Oh, je l'ai compris, mais je ne vais pas vous dire ce que j'ai fait pour résoudre le problème même si vous avez passé du temps à essayer de m'aider" élaborer sur votre solution, Sinon, vous gaspillez le temps des peuples.
Cette réponse n'expose aucune explication sur la solution appliquée par l'utilisateur Zaid Amir. Il semble qu'il parle de lui-même.
Vous pouvez exécuter un fichier bash. Voici un exemple Plus sur: http://www.jamesransom.net/?p=58 upload.sh que vous pouvez simplement exécuter comme: sh upload.sh Yourfile
Merci mais cette question était de cinq ans il y a cinq ans et c'est pour Windows comme le suggère la balise.
Sur Nix, vous pouvez faire contenttype = "$ (fichier -b -b-β-type" $ 1 ")"
Le jeu a changé de manière significative car la question a été posée, les en-têtes d'autorisation simples ne s'appliquent plus, mais il est toujours possible de fonctionner avec un script Unix Shell, comme suit.
Assurez-vous "OpenSSL" et "CURL" sont disponibles. à la ligne de commande. CONSEIL: Vérifiez la syntaxe de l'argument OpenSSL car elles peuvent varier avec différentes versions de l'outil; par exemple. OpenSSL Sha -Sha256 ... Versus OpenSSL SHA256 ...
Attention, une seule nouvelle ligne supplémentaire ou un personnage spatial supplémentaire, sinon l'utilisation de la CRLF à la place de la nouvelle ligne CHARFE vaincre la signature. Notez que vous souhaiterez peut-être utiliser des types de contenu éventuellement avec des codages pour éviter toute transformation de données via le support de communication. Vous devrez peut-être ensuite ajuster la liste des en-têtes signés à plusieurs endroits; Veuillez vous référer à Amazon S3 API Docs < / a> Pour les nombreuses conventions de conserver appliquées comme une commande alphabétique-minuscule des informations d'en-tête utilisés dans les calculs de hachage à plusieurs endroits (redondants). Je dois reconnaître que, pour Quelqu'un un peu impliqué dans la cryptographie comme moi, le schéma de signature amazonien mérite de nombreux critiques: s'excuser pour les critiques, je n'ai pas pu résister. Pourtant, reconnaissez: elle fonctionne de manière fiable, utile pour de nombreuses entreprises et un service intéressant avec une API riche.
J'étais à mi-chemin pour écrire cette chose, puis a décidé de rechercher un autre ensemble de mots-clés et trouvé cette réponse. Jusqu'à présent, c'est le plus proche que je suis arrivé, bien qu'il semble que le schéma de signature ait changé à nouveau car Amazon répond à la signature de demande que nous avons calculée ne correspond pas à la signature que vous avez fournie. ' Merci d'avoir piraté cela pour le reste d'entre nous!
"La signature calculée ne correspond pas" indique une différence entre les "CanonicalRequest" ou "StringToSign" et des en-têtes / données HTTP. Soyez très prudent avec le chemin du fichier (AWS3 connaît uniquement le chemin de vente de la godet) et considère également l'alignement le plus strict entre les en-têtes de demande et leurs annonces dans «CanonicalRequest» et «Stringtosign». Utilisez Curl -V (Verbose) pour voir des en-têtes et des chemins exacts dans votre demande HTTP. De plus, si vous (par exemple) Type de contenu ajouté, les listes d'en-têtes dans "CanonicalRequest" et "StringToSign" doivent être ajustées et "normalisées" telles que documentées dans leur API Docs dans Ref.
J'ai l'erreur suivante: de AWS "L'en-tête d'autorisation est malformé; date de transmission non valide. La date n'est pas la même que X-AMZ-DATE". Voici la clé / valeur pour cela: "X-Amz-date: 20201025T020215Z"
Je penserais (mais incertain) qu'une "date" est insérée lors de la soumission de la requête HTTP basée sur votre fuseau horaire de la machine locale et que cette valeur d'en-tête est conflit avec une date générée sous la date de X-Amz ... Assurez-vous aussi Que le temps de la machine est suffisamment aligné avec du temps officiel.
INVALIDRQUEST
C'est explicite: regardez attentivement le script, l'en-tête manquant doit être construit. Donc, vous avez très probablement une partie du script qui ne s'exécute pas comme prévu. Vérifiez l'environnement Shell Exec (notamment le comportement de la commande ECHO dans votre coquille) et poursuit des caractères non confidentiels pouvant avoir glissé. Ajoutez des traces aux échanges avec des arguments en curl -V. Les opérations de cryptographie en cascade dans une coquille comme ci-dessus sont fragiles par nature.
Résolu: manquait un curlopt pour la taille du fichier dans mon code et tout fonctionne parfaitement