Azure Storage Table API REST с включенным Curl Linux - PullRequest
Новая
       124

Azure Storage Table API REST с включенным Curl Linux

2 голосов
/ 29 мая 2020

Мне нужна помощь в создании правильного заголовка авторизации для POST в Azure Таблицы с использованием curl на Linux. Я прихожу в мир API и REST. Я использовал az cli для выполнения своих слияний, но под нагрузкой он поглощает все ресурсы в коробке, поэтому конечная цель - создать пакетные вставки из сценария ak sh. На данный момент я просто пытаюсь заставить вставку работать, но если я ошибаюсь, любые идеи относительно цели пакета были бы очень кстати.

Этот вопрос Azure Storage Table API REST с Curl очень помог, потому что это единственный полный пример, который я обнаружил, который делает что-то очень похожее из командной строки nix (а не все примеры C#, которые предоставляет MS). Используя это, я смог запросить (GET) полные таблицы, указав c сущностей / значений и c без curl -k (небезопасно) - все хорошо. Преобразование этого во вставку доказывает проблему c.

Я позаимствовал почти все из вышеупомянутого вопроса. Единственные биты, которые я изменил, - это GET> POST, accept> Content-Type, отбросил Content-Length и добавил файл cacert, который я загрузил с предложенного веб-сайта curl. Это попытка завивки ... 

# curl -v \
>      -H "Authorization: SharedKey XXXXXXX:${signature}" \
>      -H "x-ms-date: $request_date" -H "x-ms-version: 2017-07-29" \
>      -H "Content-Type: application/json; charset=UTF-8" \
>  --data @body.json "https://XXXXXXX.table.core.windows.net/YYYYYYY" \
>  --cacert cacert.pem
*   Trying <20.150.40.102>...
* TCP_NODELAY set
* Connected to XXXXXXX.table.core.windows.net (20.150.40.102) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: cacert.pem
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=*.table.core.windows.net
*  start date: May 19 11:38:54 2020 GMT
*  expire date: May 19 11:38:54 2022 GMT
*  subjectAltName: host "XXXXXXX.table.core.windows.net" matched cert's "*.table.core.windows.net"
*  issuer: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation; OU=Microsoft IT; CN=Microsoft IT TLS CA 4
*  SSL certificate verify ok.
> POST /YYYYYYY HTTP/1.1
> Host: XXXXXXX.table.core.windows.net
> User-Agent: curl/7.62.0-DEV
> Accept: */*
> Authorization: SharedKey XXXXXXX:UJs5ATaZZZZZZZZ1L3c=
> x-ms-date: Fri, 29 May 2020 13:58:52 GMT
> x-ms-version: 2017-07-29
> Content-Type: application/json; charset=UTF-8
> Content-Length: 183
>
* upload completely sent off: 183 out of 183 bytes
< HTTP/1.1 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
< Content-Length: 419
< Content-Type: application/xml
< Server: Microsoft-HTTPAPI/2.0
< x-ms-request-id: ccf4784c-4002-000a-44c1-3556f6000000
< x-ms-error-code: AuthenticationFailed
< Date: Fri, 29 May 2020 13:58:53 GMT
<
<?xml version="1.0" encoding="utf-8"?><m:error xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"><m:code>AuthenticationFailed</m:code><m:message xml:lang="en-US">Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:ccf4784c-4002-000a-44c1-3556f6000000
* Connection #0 to host XXXXXXX.table.core.windows.net left intact
Time:2020-05-29T13:58:53.9256087Z</m:message></m:error>

Это второе сообщение ALPN, похоже, не является проблемой (согласно Google), и это рукопожатие выглядит хорошо (верно?). Итак, я думаю, что у меня все хорошо с точки зрения сертификатов, ключей и т. Д. c. Я, должно быть, испортил формат string_to_sign.

Обязательные заголовки различаются между глаголами. Ссылаясь на документы MS, они советуют следующие обязательные заголовки и говорят, что порядок важен ... 

StringToSign = VERB + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedResource;

Требуются только глагол, дата и канон, поэтому ... 

POST\n\n\n${request_date}\n/XXXXXXX/YYYYYYY;

... должно быть хорошо. Однако есть также сноска, в которой говорится, что мне нужны заголовки DataServiceVersion и MaxDataServiceVersion, но они не включены в пример непосредственно над ними, и нет указания на порядок, требуемый для этих дополнительных полей. https://docs.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key#Subheading2.

Продолжая поиск в Google, кажется, что они действительно должны быть в json, поэтому я помещаю их в свое тело. json файл. 

{
   "M00":"98989898",
   "PartitionKey":"20200529",
   "RowKey":"sometext"
   "DataServiceVersion":"3.0;NetFx"
   "MaxDataServiceVersion":"3.0;NetFx"
}

Дополнительный кредит ... Ищу Вперед к пакетной конфигурации я вижу, что впереди еще больше «веселья», поэтому, если кто-то сделал это из командной строки bash / ksh / nix, поделитесь. Я чувствую, что приближаюсь, но мне трудно представить, что мне нужно построить в командной строке, когда я смотрю на это, например ...

https://docs.microsoft.com/en-us/rest/api/storageservices/performing-entity-group-transactions

(И откуда берутся идентификаторы пакетов и ревизий ??)

...