Попытка получить доступ к потоку журналов приложений Azure из curl, как предлагается на веб-странице Azure Kudu.Я в командной строке Windows 10.Это пример командной строки, которую я пытаюсь:
curl -u myUserName https://myApp.scm.azurewebsites.net/api/logstream
Enter host password for user 'myUserName':<password typed here>
В обоих случаях, curl показывает содержимое заголовка веб-страницы 401 - Несанкционированный: доступ запрещен из-за неверных учетных данных. ,Я также попытался заключить имя пользователя в двойные кавычки и экранировать знак доллара ($) обратной косой чертой (\).Не повезло.
Я должен делать что-то действительно глупое.Я прошел через несколько документов и постов, таких как официальные документы Kudu , msdn , здесь, на SO , и я думаю, что следую инструкциям.Другие источники: MSDN снова , old seirer post .
Edit
После предложений я попытался получить доступ к https://myApp.scm.azurewebsites.net/basicauth с учетными данными развертывания на уровне пользователя и учетными данными веб-развертывания VS (как с выходом, так и с выходом): не повезло.Я также снова сохранил пароль уровня пользователя, на всякий случай, если раньше допустил ошибку.
Затем я переключился с curl на клиент Insomnia.
Когда я нажал basicauth, оба с user-учетные данные уровня развертывания и учетные данные веб-развертывания, фактическая страница Kudu отображается правильно.
Когда я нажимаю api/logstream с обоими учетными данными, кажется, что запрос никогда не возвращается, что, я полагаю, связано с непрерывным потоком из вывода журнала.
Так что, похоже, что-то смешное происходит с curl из командной строки, в отличие от клиента Insomnia.Версия Curl, которую я использую:
curl 7.55.1 (Windows) libcurl / 7.55.1 WinSSL
Дата выпуска: [не выпущено]
Протоколы: файл dict ftp ftps http httpsimap imaps pop3 pop3s smtp smtps telnet tftp
Особенности: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
Снова возвращаемся в curl:
при удалении опции -u (и, следовательно, запрос пароля) и вручную добавьте базовый заголовок аутентификации, сгенерированный Insomnia, все в порядке.
Когда я использую опцию -u, передающую myUserName:myPassword, все в порядке.Таким образом, кажется, что-то похоже на то, как пароль вводится в его приглашении.
Edit # 2
Снова, после предложения @David Ebbo, подробный вывод curl показывает, чторассчитанный токен Base-64 кажется неверным.
- Рабочий - длиной 44 символа, заканчивающийся одним
=. - Значение, показанное в выводе curl
-v, имеет длину 20 символов и заканчивается двойным =. - Оба они имеют одинаковые начальные 17 символов.
Это может быть связано с тем, что завершающий символ новой строки берется как часть пароля, согласно this .Но, во всяком случае, не уверен, как двигаться дальше.На данный момент это просто вопрос понимания того, что происходит, обходные пути уже есть.Для полноты вот (отредактированный) подробный журнал:
* Trying xxx.xx.xx.xxx...
* TCP_NODELAY set
* Connected to myApp.scm.azurewebsites.net (xxx.xx.xx.xxx) port 443 (#0)
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 1/3)
* schannel: disabled server certificate revocation checks
* schannel: verifyhost setting prevents Schannel from comparing the supplied target name with the subject names in server certificates.
* schannel: sending initial handshake data: sending 186 bytes...
* schannel: sent initial handshake data: sent 186 bytes
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 2/3)
* schannel: encrypted data got 2904
* schannel: encrypted data buffer: offset 2904 length 4096
* schannel: received incomplete message, need more data
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 2/3)
* schannel: encrypted data got 818
* schannel: encrypted data buffer: offset 3722 length 4096
* schannel: sending next handshake data: sending 126 bytes...
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 2/3)
* schannel: encrypted data got 51
* schannel: encrypted data buffer: offset 51 length 4096
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 3/3)
* schannel: stored credential handle in session cache
* Server auth using Basic with user 'myUserName'
> GET /api/logstream HTTP/1.1
> Host: myApp.scm.azurewebsites.net
> Authorization: Basic {{CALCULATED TOKEN}}
> User-Agent: curl/7.55.1
> Accept: */*
>
* schannel: client wants to read 102400 bytes
* schannel: encdata_buffer resized 103424
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 1501
* schannel: encrypted data buffer: offset 1501 length 103424
* schannel: decrypted data length: 1472
* schannel: decrypted data added: 1472
* schannel: decrypted data cached: offset 1472 length 102400
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: decrypted data buffer: offset 1472 length 102400
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 1472
* schannel: decrypted data buffer: offset 0 length 102400
< HTTP/1.1 401 Unauthorized
< Content-Type: text/html
< Server: Microsoft-IIS/10.0
* Authentication problem. Ignoring this.
< WWW-Authenticate: Basic realm="site"
< Date: Wed, 13 Jun 2018 21:23:59 GMT
< Content-Length: 1293
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>401 - Unauthorized: Access is denied due to invalid credentials.</title>
{{... CONTINUES}}