HWIOAuthBundle | OAuth client integration for Symfony Supports both OAuth10a and OAuth2 | OAuth library

The underlying reason is the way Symfony generated the full-addresses from a relative path or route name.

Here's the investigation:

• The method HWI/OAuthUtils::getAuthorizationUrl() is the one that generates the OAUth auth URI and consumes the method Symfony/HttpUtils::generateUri() to get the absolute URI of the redirect_to callback that will be encoded inside the Auth URI.

• The method Symfony/HttpUtils::generateUri() generates an absolute URI (that in our case will be the callback) and to do so, the method handles 3 general cases:

  • The parameter is already an absolute URI (the return is the parameter without further processing)
  • The parameter is a relative URL (the function calls the Request class to build the proto + host + port + project-path prefix to prepend to the relative URI)
  • The parameter is a route name (the funcion calls the Router class to build the absolute URI)

In my example I was configuring a relative URL (google: "/login/check-google") in the security.yml so HttpUtils was delegating into the Request class.

Looking at the source of the Request class we observe:

• The Request class is able to use proxy headers to build the absolute class.
• But for security, by default symfony does not trust that a proxy exists merely because there are X-FORWARDED-* headers in it.
• Indeed it's more secure plus more flexible.
• There are 2 levels of security:
  • Somewhere we need to tell the Request class what is the list of trusted IPs that are proxies accessing the application.
  • Somewhere else we need to tell the Request class what specific proxy headers are trusted and what headers are not, even it supports different standards headers (RFC headers, non-RFC apache headers, etc)

Stated here https://symfony.com/blog/fixing-the-trusted-proxies-configuration-for-symfony-3-3 is that you need to configure the trusted proxies in the front-controller by calling the static method Request::setTrustedProxies();

So adding those couple of lines in the front-controller one killing non-nee4ded headers and the other with the IP ranges of the proxies, solved the problem: