Allow absolute redirect URIs

[aaw]

Currently, when you configure a redirect_uri that is an absolute URI, it has its path extracted and appended to the request domain to create the actual redirect_uri sent to Github. So, for example, if you have a redirect_uri of test1.example.com/callback but your app runs on test2.example.com, the redirect_uri sent to Github will be test2.example.com/callback. In most cases, this is the intended behavior, since Github doesn't allow redirect URIs that aren't extensions of the callback URI.

This patch allows redirect_uris that are specified as absolute URIs to retain their domains, which allows, for example, OAuth schemes where a single app is the "OAuth broker" for several other apps. See http://stackoverflow.com/a/13841857 for an example. Using this patch, I was able to set up a single OAuth broker for many apps as described in the example.

A little background to motivate why you would ever want to do this: we have a simple database admin app that takes, as configuration, a single connection url. For any database, say, db1, we expose this admin app on its own subdomain, e.g., db1.example.com. We have dozens of these admin apps and don't want to create a Github OAuth config for each individual one, so instead we set up a single db.example.com app as the "broker". When a request comes in to db1.example.com that needs authorization, it hits the Github OAuth endpoint with a redirect_uri of db.example.com/auth/github/callback/db1.example.com. When db.example.com gets the call back from Github on that path, it just fowards it (along with the code and state) back to db1.example.com/auth/github/callback, which checks the state and finishes the OAuth flow.

[atmos]

No.

[atmos]

Sorry for the blunt reply. I have no intention of supporting this type of approach. If you have multiple unique hostnames serving frontend traffic I'd suggest you setup separate applications or put them behind a load balancer.