envoy: Application following web flow for OAuth token receives 404 when proxied through Envoy

I’m seeing something very strange with an app that I’m testing out in a service mesh environment. Here’s what the setup looks like:

  • App is deployed as a pod in k8s on AWS
  • Istio 0.4.0 is installed and is using envoy as the sidecar
  • Egress rules are applied so that the app can reach *.github.com over TLS
  • URLs in the code have been rewritten to follow the http://...:443 syntax

For reference you can assume that the service’s code to get an OAuth token looks very similar to this. What’s strange is that the exact same code using the same client_id, client_secret, and code (the one that GitHub gives you in the callback) works locally. I was able to verify this by spinning up the Python repl locally, copy and pasting the same code that was deployed to AWS into the repl, providing the client_id, client_secret, and code (I grabbed the code from testing the live deployment as part of my debugging), and executing it all. I got a 200 response along with the OAuth token.

As the title says, this exact same code and execution flow throws a 404 along with 404 Not Found back to the app. I guess you could say the code is not 100% the same as the local test I did since the URLs need to be adjusted for the egress (http://github.com:443/login/oauth/access_token instead of https://github.com/login/oauth/access_token for example).

Is there something that Envoy is not handling or is stripping out from these kinds of requests?

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 25 (6 by maintainers)

Commits related to this issue

Most upvoted comments

Thanks, I’ll give this a try and circle back.

this looks like the egress for https issue. your best bet is to use includeIPRange https://istio.io/docs/tasks/traffic-management/egress.html#calling-external-services-directly to not intercept outgoing traffic unless you are able to change the client to use http on port 443