Open Lekensteyn opened 4 years ago
@Lekensteyn makes some great points.
To add to this, I'm experiencing issues with cloudflared access curl <url>
when there isn't an existing token for the URL.
In this case cloudflared
tries to open the browser to authenticate the user, with the intent of redirecting the user to the requested URL after authentication. Except I've found that when using the curl
command, cloudflared
does not properly generate the return_url
parameter. As an example, when running: cloudflared access curl https://protectedservice.domain.com/protected/path
, cloudflared
will open the following URL in the browser:
https://protectedservice.domain.com/cdn-cgi/access/cli?redirect_url=https%3A%2F%2Fprotectedservice.domain.com%3Ftoken%3D<token>%253D&token=<token>
Note the redirect_url
parameter is effectively https://protectedservice.domain.com
(and note the missing path). This results in an Invalid redirect URL
error (because the URL without the path does not have a Cloudflare Access application policy associated with it):
In contrast when doing a login
by running cloudflared access login https://protectedservice.domain.com/protected/path
, cloudflared
will open the following URL in the browser:
https://protectedservice.domain.com/cdn-cgi/access/cli?redirect_url=https%3A%2F%protectedservice.domain.com%2Fprotected%2Fpath%3Ftoken%3D<token>%253D&token=<token>
Note the redirect_url
in this instance is https://protectedservice.domain.com/protected/path
(which is correct), and correctly opens the authentication page (and returns a token upon successful authentication).
I, too, rely on the curl command to programmatically check whether the current token is still valid and results in access to the requested resource. Due to the issues outlined above, this fails, since the process halts in the browser with the Invalid redirect URL
error. I thus have to resort to setting a timeout on the curl
command, and then running the login
command in order to properly retrieve a new token.
The
cloudflared access curl
command (docs) can be used to obtain a valid authentication token and include thecf-access-token
header with the curl command line. However there were some integration challenges when naively replacing an existingcurl
invocation bycloudflared access curl
:https://www.example.com/download/file.zip
was requested, then the file~/.cloudflared/www.example.com-download-file.zip-token
would be created. For my use case, I needed the token to be scoped to a domain. Therefore I had to extract the host from the URL and usecloudflared access login https://www.example.com
instead.cloudflared access login
command prints the token. This info is sensitive even if it is only valid for a short time. It is terrible if you are doing a screencast. It would be better if it is hidden, recommending the user to use thecloudflared access token --app=www.example.com
command instead.cloudflared access token
command does not validate the token online. The token file appears to have an expiry epoch time in the JWT payload, so at minimum that can be verified if available. However due to potential clock skew and server-side expiration, I ended up with the following strategy:cloudflared access login https://www.example.com
cloudflared access token --app=www.example.com
cloudflared access token
is used, a redirect occurs to the login page. Because the final status code is 200 OK, applications which usecurl -sL -Hcf-access-token=$TOKEN $URL
will end up using the wrong data. Perhaps a HTTP status code other than 1xx and 2xx can be used? For example, 400 Bad Request or 403 Forbidden?cloudflared access curl --help
command fails withparse --help: invalid URI for request
instead of displaying a synopsis such ascloudflared access curl [options...] <url>
. The--allow-request
or-ar
option is unfortunate, the latter conflicts with curl.