saucelabs / forwarder Goto Github PK

At the moment support for env vars is limited to selected few that are evaluated in Proxy constructor.

In example test it's documented to update logging level to get more info. Unfortunately doing that breaks the tests.

--- FAIL: ExampleNew (4.02s)
got:
component=proxy output=console level=debug timestamp=2022-09-08T10:08:50+02:00 message=Target/end server started @ http://user1:[email protected]:59872
component=proxy output=console level=debug timestamp=2022-09-08T10:08:50+02:00 message=PAC template parsed: 
function FindProxyForURL(url, host) {
  if (
    dnsDomainIs(host, "intranet.domain.com") ||
    shExpMatch(host, "(*.abcdomain.com|abcdomain.com)")
  )
    return "DIRECT";

  return "PROXY 127.0.0.1:49837; DIRECT";
}

component=proxy output=console level=debug timestamp=2022-09-08T10:08:51+02:00 message=PAC server started @ http://user:[email protected]:59873
component=proxy output=console level=debug timestamp=2022-09-08T10:08:51+02:00 message=Basic auth setup for proxy @ http://u123:[email protected]:49130
component=proxy output=console level=debug timestamp=2022-09-08T10:08:51+02:00 message=Listening on 127.0.0.1:49130
component=proxy output=console level=debug timestamp=2022-09-08T10:08:52+02:00 message=Basic auth setup for proxy @ http://u456:[email protected]:49837
component=proxy output=console level=debug timestamp=2022-09-08T10:08:52+02:00 message=Listening on 127.0.0.1:49837
component=proxy output=console level=debug timestamp=2022-09-08T10:08:53+02:00 message=Client is using http://u123:[email protected]:49130 as proxy
component=goproxy output=console level=debug timestamp=2022-09-08T10:08:53+02:00 message=[001] INFO: Got request / 127.0.0.1:59872 GET http://127.0.0.1:59872/
component=proxy output=console level=debug timestamp=2022-09-08T10:08:53+02:00 message=GET 127.0.0.1:59875 -> http 127.0.0.1:59872 59872
component=goproxy output=console level=debug timestamp=2022-09-08T10:08:53+02:00 message=[001] INFO: Received response 200 OK
component=proxy output=console level=debug timestamp=2022-09-08T10:08:53+02:00 message=127.0.0.1:59875 <- 127.0.0.1:59872 200 OK (4 bytes)
component=goproxy output=console level=debug timestamp=2022-09-08T10:08:53+02:00 message=[001] INFO: Copying response to client 200 OK [200]
component=goproxy output=console level=debug timestamp=2022-09-08T10:08:53+02:00 message=[001] INFO: Copied 4 bytes to client error=<nil>
200
body
want:
200
body

FAIL

Configs are named Options which is kind of misleading because typically options refer to functional options pattern, and configuration objects are named Config or XXXConfig.

This project has MIT license that is reportedly owned by Fernando Silva, Sauce Labs - @waggledans?

When ProxyLocalhost is disabled, user can call services listing on localhost on the proxy machine.
This is exactly what we can see in #31 logs, local proxy does not hit upstream, instead it uses its own localhost to deliver the result.

Related to #31

Each relevant component (Struct?) should allow specifying a logger it uses.
Providing the logger implementation is responsibility of main package.
At the moment we are accessing logger.Get randomly it creates a troublesome coupling in da code.

v.0.1.19 crashes

2022/04/20 13:45:37 http: panic serving 127.0.0.1:64338: runtime error: invalid memory address or nil pointer dereference
goroutine 625 [running]:
net/http.(*conn).serve.func1()
        /usr/local/Cellar/go/1.18/libexec/src/net/http/server.go:1825 +0xbf
panic({0x4ace600, 0x5390eb0})
        /usr/local/Cellar/go/1.18/libexec/src/runtime/panic.go:844 +0x258
github.com/saucelabs/forwarder/pkg/proxy.New.func3(0x0, 0xa?)
        /Users/danslov/go/pkg/mod/github.com/saucelabs/[email protected]/pkg/proxy/proxy.go:708 +0x97
github.com/elazarl/goproxy.FuncRespHandler.Handle(0x4b5aca0?, 0xc000372690?, 0xc0008eedc0?)

Looks like it's related to elazarl/goproxy#318

Instead of asking devs to install some binaries let's just provide means to do that automatically.

Instead of latest use fixed tools versions.

The --local-proxy-uri is difficult to understand and uncommon way to configure a TCP/HTTP listener.
The common way would be to allow to specify the binding TCP address.

It should use the URI validation we have in other palaces.

Users should be able to configure the binary with command line flags and env variables.
This can be easily automated with Cobra + Viper, see this issue.
All of that shall happen in cmd/forwarder, Proxy gets configuration it can validate...

HTTP transport - the proxy HTTP client transport is not configured. In practice we want to be able to manage connection pool sizes timeouts etc.

Example

'ProxyConfig.LocalProxyURI' Error:Field validation for 'LocalProxyURI' failed on the 'proxyURI' tag

• Start Forwarder listening on 8081
• Start another instance of Forwarder with a PAC file listening on 8080.

function FindProxyForURL (url, host) {
    if (shExpMatch(host, '*.example.com')) {
        return 'DIRECT';
    }
    return 'PROXY localhost:8081';
}

This PAC file expects that ALL requests to www.example.com will go direct.

Execute:

$ curl -x localhost:8080 http://www.example.com
$ curl -x localhost:8080 http://www.httpbin.org
$ curl -x localhost:8080 http://www.example.com

The first request to http://www.example.com will not go via the upstream proxy (:8081) as it's configured in the PAC file.
The next request to http://www.httpbin.org will be proxied via the upstream proxy as expected.
The next request to http://www.example.com will be proxied via the upstream proxy even though Forwarder logs that the request is direct!!!!!

The setupProxyHandlers function that configures goproxy uses a strange method where everything is always configured on per request basis.

It looks like it creates race condition...
This code called for every request clearly changes the server state.

// setupUpstreamProxyConnection forwards connections to an upstream proxy.
func setupUpstreamProxyConnection(ctx *goproxy.ProxyCtx, uri *url.URL) {
	ctx.Proxy.Tr.Proxy = http.ProxyURL(uri)

Also, HandleConnectFunc returns a nil ConnectAction while it should accept the connect - this code path seems not to be tested.

Normally we should be using ReqCondition like

// Typical usage:
//	proxy.OnRequest(UrlIs("example.com/foo"),UrlMatches(regexp.MustParse(`.*\.exampl.\com\./.*`)).Do(...)

those can be also custom interface implementations that allow for more dynamic bhv.

Requirements:

• All log lines related to processing of a request should have request ID
• Request ID should be read from X-Request-ID header
• If missing it should be generated

At the moment we use 1s sleep to wait for servers to start this should be changed to active waiting.

At the moment we dump all request to debug log. It's impossible to use that in a production setting...

Nice example of http dumps is goproxy-httpdump

Requirements

• add --dump-http flag and config option to enable dumping
• use HttpLogger to nicely dump http payload

ATM no headers are added to indicate the request origin. This should be controlled by a flag.

The make test and make integration-test run the same set of tests.
The only difference is that in the "integration test" the TestNew uses https://httpbin.org/status/200 instead of the local server...

			if os.Getenv("FORWARDER_TEST_MODE") == "integration" {
				targetServerURL = "https://httpbin.org/status/200"

				if tc.args.dnsURIs != nil {
					dnsURIs = tc.args.dnsURIs
				}
			}

This could be changed to a test where we crate synthetic dns server or modify /etc/hosts

This is just to improve the usability/ergonomics.

Related work https://github.com/saucelabs/libsauceconnect/commit/d9c5a5436d9378f5417524ff59b16391976296e9

Consider this

// dial makes a new connection to the provided server (which must be
// an IP address) with the provided network type, using either r.Dial
// (if both r and r.Dial are non-nil) or else Dialer.DialContext.
func (r *Resolver) dial(ctx context.Context, network, server string) (Conn, error) {
	// Calling Dial here is scary -- we have to be sure not to
	// dial a name that will require a DNS lookup, or Dial will
	// call back here to translate it. The DNS config parser has
	// already checked that all the cfg.servers are IP
	// addresses, which Dial will use without a DNS lookup.
	var c Conn
	var err error
	if r != nil && r.Dial != nil {
		c, err = r.Dial(ctx, network, server)
	} else {
		var d Dialer
		c, err = d.DialContext(ctx, network, server)
	}

Since we replace dial function in Resolver we must make sure that we would not end up doing a name resolution.

Currently forwarder accepts string based configuration. Relevant configuration values are passed as URL encoded strings. The strings are validated using proxyURI validation. The validation produces poor error messages as noted in #55.

The SC code actually works with url.URL, it would be beneficial to:

• Replace the URI strings in configuration with *url.URL
• Add custom validation for url.URL that would report actionable error messages
• Add cobra value type that handles conversion of string to url.URL on field level and possibly calls the custom validations - so we'd have a customizable type that would allow to run custom validations from the package

Add possibility to add custom headers. The cli should use --header -H format, for reference see curl manual.

One possible solutions is to move the internal packages up or even unpack some of them to project root.

Move cmd/forwarder/run.go and cmd/forwarder/run package and allow to import the forwarder proxy cobra command.
Consider renaming run to proxy.

Many errors are written not according to best practices. This produces awkward looking error messages when wrapping errors.

Add observability by providing information on processed requests, error rate and so on.
Details need to be specified.

AutomaticallyRetryPort is a feature that allows to change desired port if the one specified by user is occupied.
This is a dangerous feature that prevents the system from failing fast.
If user wants to have always up bhv and read port from the log she can set port 0.

The promise

// client -> protected local proxy -> protected pac server - connection setup -> protected upstream proxy -> protected target.

The reality

component=proxy output=console level=trace timestamp=2022-09-08T14:17:09+02:00 message=Not proxifying request to localhost URL: http://127.0.0.1:62270/

It's easy to fix by adding ProxyLocalhost: true.

Go version should be set in a single place.

See https://github.com/abourget/goproxy/tree/master/har

Malicious user may drain server TCP connection pool by opening connections and never writing anything if no timeout is specified.

proxy.go:620:12: G114: Use of net/http serve function that has no support for setting timeouts (gosec)

Currently DNS passed as --dns-uris are applied globally. When embedded in another process this can possibly cause side effects.

In the context of #29 and other issues we shall add a test that would enable race detector to actually find something.
In that context we should add the stress tool too.

The command shall intercept SIGINT and SIGTERM.
Forwarder should expose means to gracefully stop the proxy.

• Stop accepting new connections
• Wait for ongoing connections to to close
• Specify grace period in the configuration file

DNS is currently configured after PAC.

This results in PAC server address being resolved with stock DNS server not the DNS provided to the command.

Proxy.Run function has a mutex to protect the run state, clearly if I call go p.Run twice and both runs get past the check we'd endup having 2 active servers if they can be started.

	// Do nothing if already running.
	p.mutex.RLock()
	if p.State == Running {
		logger.Get().Traceln("Proxy is already running")

		return
	}
	p.mutex.RUnlock()

This functionality could be better achieved by sync.Once or documented and delegated to caller.

proxy.go:245:62: G402: TLS InsecureSkipVerify set true. (gosec)
        ctx.Proxy.Tr = &http.Transport{TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, Proxy: nil}

Relates to #36

Debug logging requests in hot path should be guarded with implicit log level check or a dedicated flag.
Due to inefficient logger implementation the log msg needs to be created only to be discarded later.

This is needed for debug in production situations.