GitHub "Authorization callback URL" limitation

[sdarwin]

See the problem description in https://github.com/pennersr/django-allauth/issues/1483

This a feature idea. What if a Django administrator creates:

• multiple OAuth Apps in GitHub (one for each URL)
• multiple social applications in Django /admin/ (one for each URL)

---

Choice 1. In a naive implementation of this, you present an end-user visiting the website with multiple buttons in the web UI, one for each auth provider just mentioned. Obviously that's a terrible user experience, but would it work functionally?

Choice 2. Only show one button "Login with Github". The django developer adds code to their template or view, checking which URL is actually being used at the moment, and dynamically offers the correct link to the visitor.

Choice 3. django-allauth adds an optional field in a social application configuration where you can specify "web URL". django-allauth dynamically determines that a user is visiting from a particular URL, and that becomes the social application that's used. The end-user sees one button. A django developer only adds one simple button on their page, "Login with Github". django-allauth does the rest of the work behind the scenes, determining which URL is being used, and therefore which GitHub OAuth App to contact.

[sdarwin]

Perhaps I misunderstood. Checking the appearance of a "Login with GitHub" button on our website, the link is /accounts/github/login/?process=login . Maybe that means it's very automated by django-allauth already, so Choice 1 and Choice 2 won't work as suggested. You cannot just add "more buttons". Nevertheless, in Choice 3, what if a selection is made based on the existing "name" field of the social app in the database. Let's say the format will be "GH www.example.com" or "GitHub OAuth Provider www.neverssl.com". Split the string on whitespace. The last element after splitting is the domain "www.example.com". If a visitor's http request domain name matches the social auth domain name, it's a match. That's the auth to use. If there is no match... auth will likely fail anyway in the case of multiple domains. Then, choose any "GitHub" social app that is present, especially if there is only one.

edit: Or add a new optional field ""web URL" to each social app in django. If that value is set, it's used in the calculation of which social app to use when contacting GitHub.

[pennersr]

It's not fully clear to me what the topic of this issue is.

• The linked issue #1483 discusses not sending the callback URL to GItHub, but I don't see what that solves. At all times, you need to correctly specify the callback URL over at GitHub. If wrongly specified, the flow won't work. So that issue is correctly closed.
• This ticket seems to be about having multiple OAuth apps, all on one site. I think the use case is missing, or at least not clear to me. Why would a user want to chose one of those apps over the other? For authentication purposes, the end result is the same -- we obtain the (same) identity of the GitHub user for all of those apps.

[sdarwin]

I think the use case is missing, or at least not clear to me.

Yes I might have rushed into proposing ideas about solutions, without explaining the use case, or believing that the other issue was sufficient.

We have a website where the hosted domain is uncertain, is changing, and needs to be hosted on multiple domains at the same time. All of those cases. GitHub only allows you to specify a single "Authorization callback URL". Really, that means one domain. If you try to host the same site on multiple domains simultaneously, that will fail.

Another problem is if you sync the production db to the staging db. That's helpful to do during testing. However, again, the Github auth will start to fail, because a staging website runs on a different URL from the production website.

The linked issue discusses not sending the callback URL to GItHub, but I don't see what that solves.

I was referring to the first part of the original post in the other issue as a description of the problem. This text:

""" The GitHub auth provider is special in a way that you can only specify a single "Authorization callback URL" for an app in your developer applications. This is problematic when your website is using

several domains, subdomains, etc., or http and https interchangeably (i.e. both can be used). Then the callback URL allauth passes on to GitHub to redirect to will not match in many cases, and you will face:

Social Network Login Failure An error occurred while attempting to login via your social network account.

Other auth providers solve this by allowing several callback URLs, GitHub doesn't. """

The other issue then goes on to propose "not sending the callback URL", as an attempt to solve the multi-domain puzzle. I'm not suggesting that, but rather another alternative. Create "multiple OAuth Apps in GitHub (one for each URL). multiple social applications in Django /admin/ (one for each URL)". Then, could django-allauth dynamically figure out which domain was being used by a particular web visitor, and choose the correct app, from multiple ones configured in the database, to establish OAuth with GitHub.

[pennersr]

allauth already has support for having multiple OAuth apps for one and the same provider. When using the Django sites framework you can assign a site to an app, and for each given site the proper app will be used. Now, if that is too static for you, you can also implement custom domain-app matching by overriding this adapter method:

    def list_apps(self, request, provider=None, client_id=None):
        apps = super().list_apps(request=request, provider=provider, client_id=client_id)
        if provider == "github":
            # Do further filtering here ... based on the request
            ...
        return apps

As for the limitation of only having one callback URL over at GitHub, there is nothing that can be done about that on this end.

Given the above, what is still missing for your use case?

[sdarwin]

Thank you very much for the answer. I was concerned about 'sites' since it's more site-wide, while this issue is particular to oauth. We haven't yet been using that feature. But it might be the best solution. I will test.