search

bitly / oauth2_proxy

A reverse proxy that provides authentication with Google, Github or other provider
MIT License
5.1k stars 1.21k forks source link

Question: Multiple upstreams throwing 404 #394

Open cananda opened 7 years ago

cananda commented 7 years ago

I have oauthproxy on SSL with 2 upstreams (no nginx in the front) -

upstreams = [ "http://links.test.com:8000/links", "http://sonar.test.com:9000/sonar" ]

The upstreams are on http only on multiple servers:ports and different paths. I seem to get a 404 post authentication when I access oauthproxy with a path.

I see the following in the console -

2017/05/22 11:25:46 oauthproxy.go:130: mapping path "/links" => upstream "http://links.test.com:8000"
2017/05/22 11:25:46 oauthproxy.go:130: mapping path "/sonar" => upstream "http://sonar.test.com:9000"
2017/05/22 11:25:46 oauthproxy.go:157: OAuthProxy configured for Google Client ID: xxxxxx
2017/05/22 11:25:46 oauthproxy.go:167: Cookie settings: name:_oauth2proxy_test secure(https):true httponly:true expiry:168h0m0s domain:<default> refresh:disabled
2017/05/22 11:25:46 http.go:81: HTTPS: listening on 127.0.0.1:443
2017/05/22 11:26:01 oauthproxy.go:602: 127.0.0.1:33102 Cookie "_oauth2proxy_test" not present
127.0.0.1 - - [22/May/2017:11:26:01 +0530] oauthproxy.test.com GET - "/links" HTTP/1.1 "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0" 403 2483 0.000
127.0.0.1 - - [22/May/2017:11:26:02 +0530] oauthproxy.test.com GET - "/oauth2/start?rd=%2Flinks" HTTP/1.1 "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0" 302 369 0.000
2017/05/22 11:26:16 oauthproxy.go:557: 127.0.0.1:33102 authentication complete Session{test@gmail.com token:true expires:2017-05-22 12:26:16 +0530 IST refresh_token:true}
127.0.0.1 - - [22/May/2017:11:26:15 +0530] oauthproxy.test.com GET - "/oauth2/callback?state=409ae672a2968734451ea298fe165dee%3A%2Flinks&code=4%2F5sq9I8vXFZYcZo9k4_K0kQZ42mb94dzrCmEaPGCoppI" HTTP/1.1 "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0" 302 29 0.441
127.0.0.1 - test@gmail.com [22/May/2017:11:26:16 +0530] oauthproxy.test.com GET links.test.com:8000 "/links" HTTP/1.1 "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0" 301 0 0.002
127.0.0.1 - test@gmail.com [22/May/2017:11:26:16 +0530] oauthproxy.test.com GET - "/links/" HTTP/1.1 "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0" 404 19 0.000

Is this supposed to work as expected?

ploxiln commented 7 years ago

Are you sure the 404 is not coming from the upstream? Maybe you need to set --pass-host-header=False, so that "links.test.com" instead of "oauthproxy.test.com" is sent in the Host header to the upstream?

cananda commented 7 years ago

404 is not coming from upstream as accessing the links directly is successful. Will test the host header and confirm

cananda commented 7 years ago

I read a bit more on multiple domain upstream support, looks like this is not possible. Path based routing will work for the same upstream. I was trying to use multiple upstreams with path based routing

ploxiln commented 7 years ago

The only reason for "routing" of any kind is to choose one of multiple upstreams for a request.

But, this may not work in a way that is useful to you. How it works is that a request to "oauth-proxy.example.com/links/a" is proxied to "http://links.test.com:8000/links/a" while a request to "oauth-proxy.example.com/sonar/b" is proxied to "http://sonar.test.com:9000/sonar/b" - the path is not translated in any way, it is passed through as-is, so the upstream applications themselves must be using unique path prefixes.

The further complication is that the request to "http://links.test.com:8000/links/a" will resolve "links.test.com" to an IP address like "1.2.3.4", and then make a tcp connection to "1.2.3.4:8000", and then finally send the request with the header Host: oauth-proxy.example.com as it was in the original request, if you didn't configure oauth2_proxy with --pass-host-header=False.

If the upstream application gets a host header or url path which it does not expect, it may return a 404 to oauth2_proxy, even though it did not return a 404 to you when you test directly, because you're making a different direct request than you configured oauth2_proxy to make.

One way to see exactly what requests are being made and returned, is to enable debug logging in both oauth2_proxy and the upstream application, and very closely inspect the logs. Another way is to use a tool like wireshark or tcpdump on the server running oauth2_proxy.