使用 curl 拒绝 Azure Kudu 访问

Question

按照 Azure Kudu 网页的建议，尝试从 curl 访问 Azure App 日志流。我在 Windows 10 命令提示符下。这是我正在尝试的示例命令行：

curl -u myUserName https://myApp.scm.azurewebsites.net/api/logstream
Enter host password for user 'myUserName':<password typed here>

• myApp: 是我的 Azure 应用服务的名称。

• myUserName：

  • 我尝试使用从 Web 部署配置文件中获取的凭据，这是 Visual Studio 发布配置文件使用的凭据。也就是说，当用户看起来像$myApp并且密码是一些 60 字符长的字符串时。
  • 我还尝试从 Azure 门户 > MyApp > 部署凭据创建用户级部署凭据，它要求提供部署/FTP 用户名和密码

在这两种情况下，curl 都会显示网页标题401的内容- 未经授权：由于凭据无效，访问被拒绝。. 我还尝试将用户名用双引号括起来，并用反斜杠 (\) 转义美元符号 ($)。没运气。

我一定是在做一些非常愚蠢的事情。我已经阅读了几个文档和帖子，比如官方 Kudu 文档，msdn，在 SO 上，我想我正在按照说明进行操作。其他来源：再次 MSDN，旧的 seirer 帖子。

编辑

经过建议，我尝试使用用户级部署凭据和 VS Web 部署凭据（转义和未转义）访问https://myApp.scm.azurewebsites.net/basicauth：没有运气。我还再次保存了用户级密码，以防我之前犯过错误。

然后我从 curl 切换到 Insomnia 客户端。

当我basicauth使用用户级部署凭据和 Web 部署凭据点击 时，正确显示了实际的 Kudu 页面。
当我api/logstream使用两个凭据点击 时，似乎请求永远不会返回，我猜这是由于日志输出的连续流。

因此，与 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 大文件 SSPI Kerberos SPNEGO NTLM SSL

再次回到 curl：

当我删除-u选项（以及密码提示）并手动添加由 Insomnia 生成的基本身份验证标头时，一切都很好。
当我使用-u选项传递时myUserName:myPassword，一切都很好。因此，在其提示下输入密码的方式似乎确实有些问题。

编辑 #2

同样，在@David Ebbo 建议之后，详细的 curl 输出显示计算出的 Base-64 令牌似乎是错误的。

• 工作的是 44 个字符的长度，以单个=.
• 而在 curl-v输出中显示的是 20 个字符的长度，以 double 结尾=。
• 它们都共享相同的初始 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}}

Answer 1

尝试：

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

Answer 2

从其他答案继续。

用

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

其中用户名和密码是发布用户名和密码。这些可以在 Azure 门户的 Azure 功能概述菜单项中找到。单击Get publish profile以获取 XML 文件。Web Deploy在 XML 中查找发布配置文件元素。此元素包含userName和userPWD属性，它们是您的发布用户名和密码。

您的用户名很可能以$. 如果您使用 bash 或其中一种 shell，则必须在curl -u参数中使用单引号。使用双引号会导致参数替换。