Comments (5)
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.
from django-allauth.
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.
from django-allauth.
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.
from django-allauth.
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?
from django-allauth.
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.
from django-allauth.
Related Issues (20)
- Feature request: disable user passwords (while allowing logging in with a magic link and social accounts)
- Add code time tolerance
- `metadataValidUntil` cannot be configured for SAML via provider settings HOT 1
- self.request.session[INTERNAL_RESET_SESSION_KEY] not persisted HOT 1
- csrf issue HOT 1
- Third-Party Login Failure on the production server but it works fine on the localhost HOT 1
- Users' email addresses can be leaked? HOT 1
- Steam Provider doesn't appear in socialaccounts in Response from _allauth/browser/v1/config HOT 1
- account.EmailAddress: (models.W036) MySQL does not support unique constraints with conditions ref 3385 HOT 3
- Version 0.63.4 broke Cognito integration HOT 2
- Signal for when both signup and email confirmation (if required) are completed HOT 5
- How to access 'Forgot your password?' anchor element. HOT 5
- Migration account.0006_emailaddress_lower throws unique error HOT 1
- Example in the documentation provides logout with 'GET' method HOT 1
- Not seeing commit in release tag(s) HOT 3
- Cannot specify allauth as a poetry git dependency HOT 1
- "hackable accounts/ url" changes (_accounts_redirect) to middleware results in SynchronousOnlyOperation error on ASGI HOT 2
- [MFA] Add totp svg to headless ManageTOTPView HOT 4
- [Headless] Customize headless.base.response.user_data HOT 1
- Django responds very slowly when user is signing up and first logging in HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-allauth.