Advanced Usage
Creating and Populating User instances
The following adapter methods can be used to intervene in how User instances are created and populated with data
allauth.socialaccount.adapter.DefaultSocialAccountAdapter
:is_open_for_signup(self, request, socialaccount)
: The default function returns that is the same asACCOUNT_ADAPTER
insettings.py
. You can override this method by returningTrue
/False
if you want to enable/disable socialaccount signup.new_user(self, request, sociallogin)
: Instantiates a new, emptyUser
.save_user(self, request, sociallogin, form=None)
: Populates and saves theUser
instance (and related social login data). The signup form is not available in case of auto signup.populate_user(self, request, sociallogin, data)
: Hook that can be used to further populate the user instance (sociallogin.account.user
). Here,data
is a dictionary of common user properties (first_name
,last_name
,email
,username
,name
) that the provider already extracted for you.
Custom Redirects
If redirecting to statically configurable URLs (as specified in your project settings) is not flexible enough, then you can override the following adapter methods:
allauth.socialaccount.adapter.DefaultSocialAccountAdapter
:get_connect_redirect_url(self, request, socialaccount)
Customizing providers
When an existing provider doesn’t quite meet your needs, you might find yourself needing to customize a provider.
This can be achieved by subclassing an existing provider and making your changes there. Providers are defined as django applications, so typically customizing one will mean creating a django application in your project. This application will contain your customized urls.py, views.py and provider.py files. The behaviour that can be customized is beyond the scope of this documentation.
Warning
In your provider.py
file, you will need to expose the provider class
by having a module level attribute called provider_classes
with your custom
classes in a list. This allows your custom provider to be registered properly
on the basis of the INSTALLED_APPS
setting.
Be sure to use a custom id property on your provider class such that its default URLs do not clash with the provider you are subclassing.
class GoogleNoDefaultScopeProvider(GoogleProvider):
id = 'google_no_scope'
def get_default_scope(self):
return []
provider_classes = [GoogleNoDefaultScopeProvider]
Changing provider scopes
Some projects may need more scopes than the default required for authentication purposes.
Scopes can be modified via SOCIALACCOUNT_PROVIDERS
in your project settings.py file.
SOCIALACCOUNT_PROVIDERS = {
'<ProviderNameHere>': {
'SCOPE': [...]
}
}
You need to obtain the default scopes that allauth uses by
looking in allauth/socialaccount/providers/<ProviderNameHere>/provider.py
and look for def get_default_scope(self):
method. Copy those default scopes
into the SCOPE list shown above.
Example of adding calendar.readonly scope to Google scopes:
SOCIALACCOUNT_PROVIDERS = {
'google': {
'SCOPE': [
'profile',
'email',
'openid',
'https://www.googleapis.com/auth/calendar.readonly'
],
}
}