Trying to access Azure App log stream from curl, as suggested by Azure Kudu web page. I'm on Windows 10 command prompt. This is a sample command line I'm trying:
curl -u myUserName https://myApp.scm.azurewebsites.net/api/logstream
Enter host password for user 'myUserName':<password typed here>
myApp: is the name of my Azure App service.myUserName:- I tried with credentials taken from web deployment profile, the one used by Visual Studio publish profile. That is, when user looks like
$myAppand password is some 60-char long string. - I also tried creating user-level deployment credentials from Azure portal > MyApp > Deployment credentials where it asks for a deployment/FTP username and password
- I tried with credentials taken from web deployment profile, the one used by Visual Studio publish profile. That is, when user looks like
In both cases, curl shows the content of a web page title 401 - Unauthorized: Access is denied due to invalid credentials.. I tried also wrapping username within double quotes, as well as escaping the dollar sign ($) with a backward slash (\). No luck.
I must be doing something really silly. I've been through several docs and posts, like official Kudu docs, msdn, here on SO and I think I'm following the instructions. Other sources: MSDN again, old seirer post.
Edit
After suggestions, I tried to access https://myApp.scm.azurewebsites.net/basicauth with user-level deployment credentials, and with VS web deploy credentials (both escaped and unescaped): no luck. I also saved user-level password again, just in case I did a mistake before.
Then I switched from curl to Insomnia client.
When I hit basicauth, both with user-level deployment credentials and Web deploy credentials, the actual Kudu page is correctly shown.
When I hit api/logstream, with both credentials, it seems the request never returns, which I guess is due to the continuous flow from log output.
So it seems there's something funny going on with curl from command line, as opposed to Insomnia client. Curl version I'm using:
curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
Release-Date: [unreleased]
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
Back again on curl:
when I drop the -u option (and thus password prompt) and manually add the basic authentication header as generated by Insomnia, all is fine.
When I use -u option passing myUserName:myPassword, all is fine. So it really seems something in the way password is typed at its prompt.
Edit #2
Again, after @David Ebbo suggestion, the verbose curl output shows that calculated Base-64 token seems wrong.
- The working one is 44-chars long ending with a single
=. - The one shown in curl
-voutput instead is 20-chars long ending with a double=. - Both of them share the same initial 17 chars.
That might be due to trailing newline being taken as part of the password, according to this. But anyhow, not sure how to move on from here. At this point it's just a matter of understanding what's going on, the workarounds are already there. For completeness, here's the (redacted) verbose log:
* 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}}
