Idea: Option to configure providers in Django admin/database

[bufke]

Hello, this is a request for comment on an idea that could be implemented in django-allauth itself or as another package. Consider these two use cases:

• Open source project foo wants to support Login With GitLab. However foo project cannot know which providers settings can apply to users ahead of time. Today, this can be solved by instructing users to set environment variables that would ultimately be applied in SOCIALACCOUNT_PROVIDERS. However it's burdensome for the developer to create many environment setting mappings. And it may be burdensome to end users who are more comfortable configuring oauth in a web interface.
• SaaS project bar is multi tenanted and wants to enable organization admins to configure their own oauth. This cannot be done without greatly extending django-allauth as there is no way to set values such as GITLAB_URL which may be unique for every GitLab instance.

Proposed solution

Add a configuration JSONField to SocialApp. Let it be configured in django admin. When set, prefer this field for settings. When null, use SOCIALACCOUNT_PROVIDERS. This behavior would not introduce any breaking change nor make users adjust to a new system who don't wish to. Having two systems to do the same thing, however, would increase code maintenance burden.

[pennersr]

I am not sure I fully understand, but you can already fully manage social apps without having provider settings in your settings.py. You can even have multiple providers of the same type, and hook them up to a site (as in, django.contrib.sites.models.Site). So, what kind of data do you expect to store in the proposed JSONField ?

[bufke]

The current implementation, in my understanding, allows editing only name/client/secret keys. This is not always sufficient, as in the case of the GITLAB_URL which may be gitlab.com or gitlab.myinstance.com. Site A may want gitlab.com while Site B wants their own self hosted GitLab. It would be hard to predict which provider specific settings need tweaked per social app. The JSONField would allow anything configurable in SOCIALACCOUNT_PROVIDERS to be set in the database. URL is the most obvious thing to store, but I could imagine other settings as well. One GitLab instance may be configured differently from another. One set of users may want to sync a lot of data while another as little as possible and thus need to change scopes.

[bufke]

Here's two examples of what I want to solve:

• It would remove the need (or greatly simplify) for merge requests like this one. Any open source project using django-allauth would end up needing a bunch of duplicated work around this mapping of settings to allauth providers.
• https://github.com/pennersr/django-allauth/issues/3073 I'm aware that this work is being done to use on the non-profit and open source project KoboToolbox. If we could set the configuration values in the database, it would make it easy for this developer's organization to use KoboToolbox with their private oauth. KoboToolbox maintains a "free for Humanitarian Organizations" hosted instance of it's software and we'd be happy to add organization specific data in our database. Some day our end users might be able to set this themselves. But it doesn't really make sense to accept organization specific code or even an environment variable. And we can't have end users setting environment variables that map to settings.py values.

I am affiliated with both projects and happy to work on a pull request. I believe this would be useful to any open source project that is a end user facing application (as opposed to a library) and uses django-allauth. I would love to contribute this upstream. I could of course code it directly into these projects instead if you believe the use case is out of scope.

[mario-moreira]

SaaS project bar is multi tenanted and wants to enable organization admins to configure their own oauth. This cannot be done without greatly extending django-allauth as there is no way to set values such as GITLAB_URL which may be unique for every GitLab instance.

I would be very interested in this.

Other alternative approach could be to have an app template, to be added to the project bar, that could implement this functionality and to be easily customized by the project. This makes any sense?

[bufke]

@pennersr could you give your opinion as to whether you would want a feature like this upstream? If not - we may proceed to make it as a custom provider and it's own pypi package. Should we choose to go upstream, KoboToolbox may be willing to fund your time for planning and code review.

The summary of the request is that multiple users or django admin users (who may not be server admins) can set their oauth/oidc credentials. They would do so for an application running on just one domain (not Sites). Multiple users may choose to use the same provider, for example a private Azure AD. Examples of this workflow: Slack, GitHub, Notion, GitLab, Figma all offer SaaS services that support SSO through SAML and/or oauth.

[pennersr]

On the latest main branch (since cc5279bb) the SocialApp model gained a settings JSON field. Additionally, you can configure any OpenID Connect provider now by adding a new app via the Django admin. So now, this would only be a matter of sourcing the relevant setting (like GITLAB_URL) from the app.settings. Would be happy to accept a pull request for the various providers that need this.

[pennersr]

Closed via 5db1b482