Azure Kudu Доступ запрещен с помощью curl

Question

Попытка получить доступ к потоку журналов приложений 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>

• myApp: имя моей службы приложений Azure.

• myUserName:

  • Я попытался использовать учетные данные, взятые из профиля веб-развертывания, который использовался в профиле публикации Visual Studio. То есть когда пользователь выглядит $myApp а пароль - строка длиной около 60 символов.
  • Я также попытался создать учетные данные развертывания на уровне пользователя на портале Azure> MyApp > учетные данные развертывания, где запрашиваются имя пользователя и пароль для развертывания /FTP

В обоих случаях, curl показывает содержимое заголовка веб-страницы 401 - Несанкционированный: доступ запрещен из-за неверных учетных данных., Я также попытался заключить имя пользователя в двойные кавычки, а также экранировать знак доллара ($) обратной косой чертой (\). Неудачно.

Я должен делать что-то действительно глупое. Я прошел через несколько документов и постов, таких как официальные документы по Kudu, msdn, здесь, на SO, и я думаю, что следую инструкциям. Другие источники: опять MSDN, старый пост seirer.

редактировать

После предложений я попытался получить доступ к https://myapp.scm.azurewebsites.net/basicauth с учетными данными развертывания на уровне пользователя и с учетными данными развертывания веб-сайта VS (как с выходом, так и с выходом): не повезло. Я также снова сохранил пароль уровня пользователя, на случай, если раньше допустил ошибку.

Затем я переключился с curl на бессонницу клиента.

Когда я ударил basicauthкак с учетными данными развертывания на уровне пользователя, так и с учетными данными веб-развертывания, фактическая страница Kudu отображается правильно.
Когда я ударилapi/logstreamс обоими учетными данными кажется, что запрос никогда не возвращается, что, я полагаю, связано с непрерывным потоком из вывода журнала.

Так что, кажется, что-то смешное происходит с curl из командной строки, в отличие от клиента Insomnia. Curl версия, которую я использую:

curl 7.55.1 (Windows) libcurl / 7.55.1 WinSSL
Дата выхода: [не выпущено]
Протоколы: файл dict ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Особенности: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL

Вернемся снова на локон:

когда я бросаю -u вариант (и, следовательно, запрос пароля) и вручную добавить базовый заголовок аутентификации, как генерируется Insomnia, все в порядке.
Когда я использую-uвариант прохожденияmyUserName:myPassword, Все хорошо. Так что действительно похоже на то, как пароль вводится в его подсказке.

Редактировать № 2

Опять же, после предложения @David Ebbo, подробный вывод curl показывает, что вычисленный токен Base-64 кажется неверным.

• Рабочий - 44 символа, заканчивающийся одним=,
• Тот, который показан в curl-vвместо этого получается длинный 20-символьный символ, заканчивающийся двойным=,
• Оба они имеют одинаковые начальные 17 символов.

Это может быть связано с тем, что завершающий символ новой строки воспринимается как часть пароля. Но, во всяком случае, не уверен, как двигаться дальше отсюда. На данный момент это просто вопрос понимания того, что происходит, обходные пути уже есть. Для полноты вот (отредактированный) подробный журнал:

*   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}}

Answer 1

Чтобы следовать из других ответов.

Использовать

curl -u 'myUserName:password' https://myApp.scm.azurewebsites.net/api/logstream

Где имя пользователя и пароль - это имя пользователя и пароль публикации. Их можно найти на портале Azure в пункте меню Обзор функций Azure. НажмитеGet publish profileчтобы получить файл XML. ИщитеWeb Deployопубликовать элемент профиля в XML. Этот элемент содержитuserName а также userPWD атрибуты, которые являются вашим именем пользователя и паролем публикации.

Скорее всего, ваше имя пользователя будет начинаться с $. Если вы используете bash или одну из этих командных интерпретаторов, вам придется использовать одинарные кавычки в вашемcurl -uпараметр. Использование двойных кавычек приведет к подстановке параметров.

Answer 2

Пытаться:

curl -u 'myUserName:password' https://myApp.scm.azurewebsites.net/api/logstream