Adapter#

class allauth.socialaccount.adapter.DefaultSocialAccountAdapter(request=None)#

The adapter class allows you to override various functionality of the allauth.socialaccount app. To do so, point settings.SOCIALACCOUNT_ADAPTER to your own class that derives from DefaultSocialAccountAdapter and override the behavior by altering the implementation of the methods according to your own needs.

can_authenticate_by_email(login, email)#

Returns True iff authentication by email is active for this login/email.

This can be configured with a "email_authentication" key in the provider app settings, or a "VERIFIED_EMAIL" in the global provider settings (SOCIALACCOUNT_PROVIDERS).

generate_state_param(state: dict) → str#: To preserve certain state before the handshake with the provider takes place, and be able to verify/use that state later on, a state parameter is typically passed to the provider. By default, a random string sufficies as the state parameter value is actually just a reference/pointer to the actual state. You can use this adapter method to alter the generation of the state parameter.

get_connect_redirect_url(request, socialaccount)#: Returns the default URL to redirect to after successfully connecting a social account.

get_provider(request, provider, client_id=None)#: Looks up a provider, supporting subproviders by looking up by provider_id.

is_email_verified(provider, email)#

Returns True iff the given email encountered during a social login for the given provider is to be assumed verified.

This can be configured with a "verified_email" key in the provider app settings, or a "VERIFIED_EMAIL" in the global provider settings (SOCIALACCOUNT_PROVIDERS). Both can be set to False or True, or, a list of domains to match email addresses against.

is_open_for_signup(request, sociallogin)#

Checks whether or not the site is open for signups.

Next to simply returning True/False you can also intervene the regular flow by raising an ImmediateHttpResponse

list_apps(request, provider=None, client_id=None)#: SocialApp’s can be setup in the database, or, via settings.SOCIALACCOUNT_PROVIDERS. This methods returns a uniform list of all known apps matching the specified criteria, and blends both (db/settings) sources of data.

new_user(request, sociallogin)#: Instantiates a new User instance.

on_authentication_error(request, provider, error=None, exception=None, extra_context=None)#

Invoked when there is an error in the authentication cycle. In this case, pre_social_login will not be reached.

You can use this hook to intervene, e.g. redirect to an educational flow by raising an ImmediateHttpResponse.

populate_user(request, sociallogin, data)#

Hook that can be used to further populate the user instance.

For convenience, we populate several common fields.

Note that the user instance being populated represents a suggested User instance that represents the social user that is in the process of being logged in.

The User instance need not be completely valid and conflict free. For example, verifying whether or not the username already exists, is not a responsibility.

pre_social_login(request, sociallogin)#

Invoked just after a user successfully authenticates via a social provider, but before the login is actually processed (and before the pre_social_login signal is emitted).

You can use this hook to intervene, e.g. abort the login by raising an ImmediateHttpResponse

Why both an adapter hook and the signal? Intervening in e.g. the flow from within a signal handler is bad – multiple handlers may be active and are executed in undetermined order.

save_user(request, sociallogin, form=None)#: Saves a newly signed up social login. In case of auto-signup, the signup form is not available.

validate_disconnect(account, accounts) → None#: Validate whether or not the socialaccount account can be safely disconnected.