Closed apa512 closed 7 years ago
This is a bug in the underlying Java client. See this issue for details. There is a workaround though. Configure the client with a realm using the same auth config as your proxy and both :preemptive
and :target-proxy
set to true
:
(def proxy
{:host "myproxy.net"
:protocol :http
:port 8080
:user "myuser"
:password "mypassword"})
(def realm
{:user "myuser"
:password "mypassword"
:preemptive true
:target-proxy true})
(def client (http/create-client :proxy proxy :realm realm))
Thanks, but unfortunately I still can't get it to work. Was the realm user/password supposed to be for proxy auth or basic auth? Either way the Github API still ignores basic auth whenever I'm using a proxy.
Maybe I'm missing something but it doesn't look like create-client cares about :realm
at all.
Yes, you're right, that should be (http/create-client :proxy proxy :auth realm)
but I can't get that to work either. I've been able to get this to work before though, but I can't seem to right now. I'll look into it some more.
Great! I'm using clj-http for now when both proxy and basic auth are needed, but it would sure be nice to switch to http.async.client for everything.
This works, in my experience:
(http/create-client :proxy {:host "proxy.example.org" :port 8080}
:auth {:user "proxyusername" :password "proxypassword"
:preemptive true :target-proxy true})
If this doesn't work for you, e.g. if you get a 404 response, then look for whether you are getting 407 Proxy Authentication Required
in the logs, which would mean that your username/password is incorrect.
fwiw: The variable realm
in this thread is a bit of a misnomer. The HTTP realm is just a string. For example, this header response from the proxy Proxy-Authenticate: Basic realm="Password Required"
has realm "Password Required"
. (http://stackoverflow.com/a/12701105)
@pbostrom pointed out to me that the issue starting this thread is authenticating both the proxy and the endpoint. My example only authenticates the proxy. Investigating further ...
Alright, I've been doing a little research into this, it looks like my workaround does not work when both the target and the proxy require authentication. Fortunately it's been fixed in the underlying Java client recently via this issue. Once it's released I'll update our library to pull in the fix.
Getting authentication error unless I remove the proxy settings.