Da mein Backend ist Beego (Golang) und Azure Storage Service SDK für Go nicht zur Verfügung gestellt, muss ich manuell erstellen Blob-Upload-Prozess. Hier ist mein Workflow:Azure Storage legte Blob REST API: Die MAC-Signatur unterscheidet sich von Azure berechnete Signatur (fehlende Inhalt-Typ)
- Mit Dropzonejs als Frontend, Benutzer zieht eine Datei in den Browser zum Hochladen.
- Im Dropzone addedfile-Handler fordert der Client mein Backend auf, eine Authentifizierung mit Daten wie meinem Speicherkonto, Dateiname/-länge und anderen x-ms-Headern zu erstellen.
- Die Auth-Sig zurückgegeben und ich trigger Dropzone XMLHttpRequest.send() auf die URL von Azure Put Blob API, mit der Auth-sig.
- Azure gibt Fehler zurück und ich fand, dass mein Back-End das Sig nicht mit Daten vom Inhaltstyp berechnete.
AuthenticationFailed
Server konnte die Anforderung authentifizieren. Stellen Sie sicher, dass der Wert des Autorisierungsheaders ordnungsgemäß einschließlich der Signatur gebildet wird. RequestId: daefeaf4-0001-0021-74d6-f4a4cf000000 Zeitpunkt: 2016-08-12T20: 16: 35.5410039ZDie MAC-Signatur, die in der HTTP-Anfrage 'xxxx' gefunden wurde, ist nicht mit einer berechneten Signatur identisch. Server verwendet folgende Zeichenkette zum Signieren: 'PUTmultipart/form-data; boundary = ---- WebKitFormBoundaryn9qZe6obJbXmk5Ko
x-ms-Blob-Typ: BlockBlob x-ms-date: Fr, 12. August 2016 20.16.36 GMT x-ms-Version: 2015.12.11 /myaccount/user-files/id_hex/57116204071.pdf '.
Das Problem ist die zufällige Folge von Grenz in Content-Type (multipart/form-data; boundary=----WebKitFormBoundaryn9qZe6obJbXmk5Ko
) wird zufällig durch den Browser nach xmlhttprequest.send erzeugt() (in Schritt 3). Woher weiß ich, wie die Grenzzeichenfolge BEFORE xmlhttprequest.send() (in Schritt 2) sein wird?