Allow For Configuration of Redirect URI

Subtitle: Don’t build redirect_uri based on current URL if x is set

This MIGHT be a no-op, but after a few hours of poking I couldn’t find a solution in the current config. I might just be dense about Django internals; if so, I apologize.

Scenario

Nginx proxy/static resource server (docker container: my_proxy) Django app in the backend configured (docker app: my_portal)

When a user hits “awesome.example.com/login/github”, my_proxy receives it and relays it to the my_portal. The Django app then redirects over to Github for the authentication flow, but it uses the url name it sees on the HTTP request from the proxy: http://my_portal/complete/github/redirect_state/....

Obviously Github doesn’t handle this well after I authenticate on their end, when it redirects back to my top-level domain,with this value I get a redirect_uri error:

Authentication failed: The redirect_uri MUST match the registered callback URL for this application.

Work Around

To work around this I think I can rewriting the headers on the proxy from Nginx to use the top-level domain host that I’m working on (i.e. forwarding awesome.example.com to my_portal instead of addressing it as my_portal). But I believe this prevents (or at least increasingly restricts) me from spinning up multiple Django app backends to serve the application.

Ask

Being able to name my application servers whatever internal name I want, but configure the redirection URL would allow me to keep.

The idea that I think works is allowing the hostname to be overwritten by a setting in Django. I’m bad at naming such things, but SOCIAL_APP_FQDN or REDIRECTION_BASE_URL would let me configure the plugin to generate redirect_uri values that match my app domain, rather than a container host or internal server IP/FQDN.

Alternatives

The answer could very well be “this overcomplicates the social stack” or “nobody does it the way you’re describing you madperson”. If anyone has any guidance or feedback here that I could work into some documentation I would appreciate it!

[raymondberg]

It’s been a long time, but I believe the key was forwarding the HTTP_HOST which in Nginx looked like the following:

proxy_set_header Host $host;

And then including the protocol (because I had issues with HTTPS URIs):

SECURE_PROXY_SSL_HEADER=('HTTP_X_FORWARDED_PROTO', 'https')

I hope this helps.

[omab]

I rather keep this out of the lib, building URIs is already done properly by the different frameworks we integrate with. In the case of Django, this library uses request.build_absolute_uri(path), which relies on _get_raw_host(), this method uses the following values (in the following order):

• HTTP_X_FORWARDED_HOST Header that can be set by nginx (quite common practice, and I fail to see why that it’s restrictive to spawn several my_portal instances)
• HTTP_HOST Header sent by the client, in the case of my_portal the client is the my_proxy, this value can be set by nginx as well.
• SERVER_NAME Environment value, you can set this in the my_portal environment values when running it.

Setting any of the values above should get you going, the good thing about the options above, is that it lets you reuse the my_portal instances and serve the same app under different hosts without any code change.

Another alternative is to override the built-in strategy and re-define the build_absolute_uri() method to use you custom value, then set the SOCIAL_AUTH_STRATEGY setting to point to your custom version.