Support forward_proxy authentication

[amejia1]

Does ferron's forward_proxy support authentication with the use of a Proxy-Authorization HTTP header?

I am trying to start a simple forward proxy which requires basic authentication but I can't get it to require authentication. This is the configuration I tried so far (comes from something I am working on at here).

// This is for starting a simple forward proxy that requires basic auth. The only valid credentials will be 'test:123?45>6'. The
// docker command to run is the following (assuming the current working directory is the top-level source directory for rustup).
//
// $ docker run --detach --name ferron-forward-proxy --publish 9080:9080 --volume "$(pwd):/mnt/cwd" ferronserver/ferron:2 ferron --config /mnt/cwd/tests/test-dist-server-resources/ferron-forward-proxy.kdl
//
// For powershell users, the equivalent command is the following.
//
// > docker run --detach --name ferron-forward-proxy --publish 9080:9080 --volume "$(Get-Location):/mnt/cwd" ferronserver/ferron:2 ferron --config /mnt/cwd/tests/test-dist-server-resources/ferron-forward-proxy.kdl
//
// Once the server is started, have rustup use it by setting the necessary environment variables.
//
// $ export ALL_PROXY="http://localhost:9080"
// $ export RUSTUP_PROXY_AUTHORIZATION_HEADER="Basic $(printf 'test:123?45>6' | base64)"
//
// In powershell, the equivalent commmands are...
//
// > $env:ALL_PROXY = "http://localhost:9080"
// > $env:RUSTUP_PROXY_AUTHORIZATION_HEADER = "Basic $([Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes('test:123?45>6')))"
//
// The 'RUSTUP_LOG' environment variable should also be set so you can see what server is being used for web requests. Once
// testing is done, the server can be stopped using the following command.
//
// $ docker stop ferron-forward-proxy && docker rm ferron-forward-proxy

:9080 {
  log_date_format "%d/%b/%Y:%H:%M:%S %z"
  log_format "{client_ip} - {auth_user} [{timestamp}] \"{method} {path_and_query} {version}\" {status_code} {content_length} \"{header:Referer}\" \"{header:User-Agent}\""
  log "/mnt/cwd/tests/test-dist-server-resources/logs/forward-proxy-access.log"
  error_log "/mnt/cwd/tests/test-dist-server-resources/logs/forward-proxy-error.log"
  status 407 users="test"
  user "test" "$argon2id$v=19$m=19456,t=2,p=1$emTillHaS3OqFuvITdXxzg$G00heP8QSXk5H/ruTiLt302Xk3uETfU5QO8hBIwUq08"
  forward_proxy
}

// The reverse proxy configuration is added here so that when the RUSTUP_DIST_SERVER is set to point to the test ferron dist server which uses
// 127.0.0.1 or localhost, it will work within the container.
:8080 {
  log_date_format "%d/%b/%Y:%H:%M:%S %z"
  log_format "{client_ip} - {auth_user} [{timestamp}] \"{method} {path_and_query} {version}\" {status_code} {content_length} \"{header:Referer}\" \"{header:User-Agent}\""
  log "/mnt/cwd/tests/test-dist-server-resources/logs/dist-server-access.log"
  error_log "/mnt/cwd/tests/test-dist-server-resources/logs/dist-server-error.log"
  status 401 users="test"
  user "test" "$argon2id$v=19$m=19456,t=2,p=1$emTillHaS3OqFuvITdXxzg$G00heP8QSXk5H/ruTiLt302Xk3uETfU5QO8hBIwUq08"
  proxy "https://static.rust-lang.org/"
  proxy_request_header_remove "Authorization"
  proxy_request_header_remove "Proxy-Authorization"
}

[amejia1]

I ended up using mitmproxy to implement the test forward proxy that requires authentication. The command I used (linked here) is the following.

docker run --detach --name rustup-test-forward-proxy --net rustup-test-network --interactive --tty --publish 9080:9080 mitmproxy/mitmproxy mitmdump --mode regular@0.0.0.0:9080 --proxyauth 'test:123?45>6'

It would still be great if ferron supported requiring authentication for forward proxies as it would simplify the setup of the test environment I need.

[DorianNiemiecSVRJS]

Thank you for the feature request!

I have just added the support for HTTP Basic authentication for forward proxying in the 6c0a4db commit. That means that the next version of Ferron 2 is going to support this.

Here is an example configuration for an authenticated forward proxy:

:8080 {
  user "test" "$2b$10$hashedpassword12345" // Replace with your username and hashed password (which can be generated with "ferron-passwd")
  forward_proxy_auth
  forward_proxy
}

[amejia1]

Thanks! I will make sure to try out the new change.

[amejia1]

I was able to checkout the latest changes and the new forward proxy authentication support works for me. I also noticed no logs were being written at the location I specified. This is the configuration I used.

:9080 {
  log_date_format "%d/%b/%Y:%H:%M:%S %z"
  log_format "{client_ip} - {auth_user} [{timestamp}] \"{method} {path_and_query} {version}\" {status_code} {content_length} \"{header:Referer}\" \"{header:User-Agent}\""
  log "/mnt/cwd/tests/resources/logs/forward-proxy-access.log"
  error_log "/mnt/cwd/tests/resources/logs/forward-proxy-error.log"
  user "test" "$argon2id$v=19$m=19456,t=2,p=1$emTillHaS3OqFuvITdXxzg$G00heP8QSXk5H/ruTiLt302Xk3uETfU5QO8hBIwUq08"
  forward_proxy_auth
  forward_proxy
}

Do the logs go elsewhere by default?

[DorianNiemiecSVRJS]

I was able to checkout the latest changes and the new forward proxy authentication support works for me. I also noticed no logs were being written at the location I specified. This is the configuration I used.

:9080 {
  log_date_format "%d/%b/%Y:%H:%M:%S %z"
  log_format "{client_ip} - {auth_user} [{timestamp}] \"{method} {path_and_query} {version}\" {status_code} {content_length} \"{header:Referer}\" \"{header:User-Agent}\""
  log "/mnt/cwd/tests/resources/logs/forward-proxy-access.log"
  error_log "/mnt/cwd/tests/resources/logs/forward-proxy-error.log"
  user "test" "$argon2id$v=19$m=19456,t=2,p=1$emTillHaS3OqFuvITdXxzg$G00heP8QSXk5H/ruTiLt302Xk3uETfU5QO8hBIwUq08"
  forward_proxy_auth
  forward_proxy
}

Do the logs go elsewhere by default?

I tried configuration very similar to yours (but with access logs going to /dev/stdout and error logs going to /dev/stderr), and it seems like when I send a request through a forward proxy, a CONNECT request is logged into the console...

[amejia1]

Alright, logging to /dev/stderr works for me and will work better for my testing needs. Thanks!