Closed seagullmouse closed 1 year ago
Hi @seagullmouse, sorry that you're running into an issue here!
Can you share the output of doing an unauthenticated curl against our API? I'm suspecting a networking issue.
curl -v 'https://api.doppler.com/v3/projects'
~/Documents/code/rise/rise-pol main curl -v 'https://api.doppler.com/v3/projects'
* Trying 172.66.40.54:443...
* Connected to api.doppler.com (172.66.40.54) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=doppler.com
* start date: Nov 24 00:00:00 2022 GMT
* expire date: Feb 21 23:59:59 2023 GMT
* subjectAltName: host "api.doppler.com" matched cert's "*.doppler.com"
* issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x148811000)
> GET /v3/projects HTTP/2
> Host: api.doppler.com
> user-agent: curl/7.79.1
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 401
< date: Fri, 20 Jan 2023 15:50:07 GMT
< content-type: application/json; charset=utf-8
< content-length: 131
< cf-ray: 78c8f6cafa0676f6-LHR
< etag: W/"83-wz0cc/Q3w4uW/SNOdV478Au1wJc"
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< via: 1.1 google
< cf-cache-status: DYNAMIC
< alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
< content-security-policy: default-src 'self';base-uri 'self';block-all-mixed-content;font-src 'self' https: data:;frame-ancestors 'self';img-src 'self' data:;object-src 'none';script-src 'self';script-src-attr 'none';style-src 'self' https: 'unsafe-inline';upgrade-insecure-requests
< cross-origin-opener-policy: same-origin
< referrer-policy: strict-origin
< x-content-type-options: nosniff
< x-dns-prefetch-control: off
< x-download-options: noopen
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-request-id: e03c2b52-c20f-4fb6-8bf5-6597172dc7b2
< x-xss-protection: 0
< server: cloudflare
<
* Connection #0 to host api.doppler.com left intact
{"messages":["Please provide an api key. You can learn more at https://docs.doppler.com/reference#authentication"],"success":false}% ~/Documents/code/rise/rise-pol main
OK, that request is looking solid to me. Can you try a POST?
curl -X POST https://api.doppler.com/v3/auth/cli/authorize -H 'Content-Type: application/json' --data '{"code": "test"}'
{"messages":["Invalid auth code"],"success":false}%
Does the login perform some frequent polling of the API? I wonder if my work has some policy on network traffic and thinks this is a threat.
It does indeed -- the CLI makes that /v3/auth/cli/authorize
request every 2 seconds to see if the auth code has been registered via the Doppler dashboard. If you retry the doppler login --debug
command after not having run it for awhile, do you see fewer failures? I noticed that our analytics POST is also failing in your original logs.
You could also try running that curl every 2 seconds and see if it starts failing. That would be a pretty telling piece of evidence.
Couple of observations
Is there a workaround to get a token onto my machine?
Interesting. One workaround would be to configure your CLI to use a Doppler personal token for authentication. Click on the "Tokens" link in the left menu and select the "Personal" tab. You can only have one personal token at a time so you'll need to roll your existing personal token if you already have one.
Once you've copied the token secret, you can load it into the CLI with pbpaste | doppler configure set token
.
Thanks.
I've tried with the personal token but still run into issues with the CLI.
E.g.
doppler configs
Unable to fetch configs
Doppler Error: Get "https://api.doppler.com/v3/configs?per_page=100&project=": EOF
doppler secrets -p **** -c local get DOPPLER_CONFIG --plain
Unable to fetch secrets
Doppler Error: Get "https://api.doppler.com/v3/configs/config/secrets?config=local&include_dynamic_secrets=false&project=****&secrets=DOPPLER_CONFIG": EOF
Something is more fundamentally wrong here.
Darn. And I'm guessing that this works for you?
curl -H "Authorization: Bearer $(doppler configure get token --plain)" 'https://api.doppler.com/v3/configs?project=YOUR_PROJECT_NAME'
I've finally found a related issue at my company. They have a network filter installed that is buggy.
Thanks for your help on this!
Awesome, I'm glad you were able to track it down!
Describe the bug When I run
doppler login
I hit errors on a brand new Mac M1.To Reproduce Steps to reproduce the behavior. Please include output from running the command with
--debug
.The same error occurs with ? Open the authorization page in your browser? (Y/n) = n
Expected behavior I should be able to login
Screenshots If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
CLI Version: Version: v3.53.0
Additional context Add any other context about the problem here.