# 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 as `ACCOUNT_ADAPTER` in `settings.py`. You can override this method by returning `True`/`False` if you want to enable/disable socialaccount signup.

  - `new_user(self, request, sociallogin)`: Instantiates a new, empty `User`.

  - `save_user(self, request, sociallogin, form=None)`: Populates and saves the `User` 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'
            ],
        }
    }