Add basic proxy authentication support via HTTP[S]_PROXY #249
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
can you please consdiser reviewing patch to add support for basic proxy authentication via the HTTP[S]_PROXY environment variables. It addresses #248.
The implementation extracts the
usernameandpasswordfrom the proxy URL and passes them to Hato by setting an authenticator option inbuild-http-client(as{:user "username" :pass "password"}). Unfortunately, configuring a globaljava.net.Authenticatordoes not work here, as the Java HTTP client used by Hato does not honor it, so the authenticator needs to be provided on each hato request instead.Because it's critical that this option is never omitted from any hato request (otherwise some calls would skip basic authentication), I added a
eca.client-test-helpers/with-client-proxiedtest macro that routes Hato requests through an embeddedLittleProxyinstance. This makes it possible to reliably test that requests pass through the proxy, and should also be useful for testing other HTTP related behavior. I also switched proxy configuration from usinghttp[s].proxyHostto Hato's:proxyjava.net.ProxySelector, which can be reset in tests (unlikehttp.proxyHost, which is resolved only once).While doing this, I went overboard and added unit tests for every Hato based request in eca. I believe these tests add value beyond proxy authentication itself, but I'm happy to unwind or simplify anything if it makes the review easier.
Finally, I introduced a
--proxyflag to theintegration-testbb task. It spins up aTinyproxyinstance, sets the proxy environment variables, and verifies that all requests go through the proxy by checking for an additional header in the mock server (otherwise the request is rejected with 403). This flag is enabled in the GH workflow when testing the binary on Ubuntu.In summary the changes are:
http[s]_proxy/HTTP[S]_proxyenv vars inproxy.clj, producing a map with:host,:port,:username, and:password. Support both lower and uppercase names because they're case sensitive on MS-Windows.client_http.clj, which turns that map into Hato:proxyand:authenticatoroptions, builds an HTTP client, and exposes it via a dynamic*hato-http-client*bound as the root client.main.cljto initialize*hato-http-client*with the correct proxy configuration.:http-client (client/merge-with-global-http-client http-client), combining the global proxy client with any per-request options (including customhttpClientproviders).client_test_helpers.cljwith awith-client-proxiedmacro to route requests through an embedded LittleProxy instance for unit tests, returning controlled fake responses. Add LittleProxy as a:testdependency (and updatedeps-lock.json).integration-testbb task with the--proxycommand line option, which setshttp_proxyand verifies routing through Tinyproxy. Update the GH workflow toubuntu-24.04to support Tinyproxy.--devto run from source,--list-nsto list all test namespaces and--nsto restrict the namespaces executed.I left out the changelog and documentation for now, pending feedback on the above.