0.34.0 (2017-10-29)

Security notice

The "Set Password" view did not properly check whether or not the user already had a usable password set. This allowed an attacker to set the password without providing the current password, but only in case the attacker already gained control over the victim's session.

0.33.0 (2017-08-20)

Security: password reset tokens are now prevented from being leaked through the password reset URL.
New providers: Patreon, Authentiq, Dataporten.
Dropbox has been upgraded to API V2.
New translation: Norwegian.

0.32.0 (2017-04-27)

Improved AJAX support: the account management views (change/set password, manage email addresses and social connections) now support AJAX GET requests. These views hand over all the required data for you to build your frontend application upon.
New providers: Dwolla, Trello.
Shopify: support for per-user access mode.

In previous versions, the views only responded with JSON responses when issuing AJAX requests of type POST. Now, the views also respond in JSON when making AJAX GET requests.
The structure of the response for AJAX requests has changed. Previously, it contained a form_errors key containing all form validation errors, if any. Now, it contains a form key that describes the complete form, including the fields. Field specific errors are placed in form.fields['some_field'].errors, non-field errors in form.errors.
The parameters passed to the Facebook JS SDK FB.init() method used to contain cookie, status, and xfbml, all set to true. These parameters are no longer explicitly passed. You can use the newly introduced INIT_PARAMS provider setting to provide your own values.

0.31.0 (2017-02-28)

Django 1.7 / Python 3.2 compatibility has been dropped.
Due to providers being registered in the same file as their definition it was impossible to subclass a provider without having the parent be registered. This has been addressed. If you have implemented a custom provider, you will need to change providers.registry.register(CustomProvider) into provider_classes = [CustomProvider].

0.30.0 (2017-01-01)

Changed the algorithm that generates unique usernames. Previously, in case the provider did not hand over any information to base the username on, the username "user" extended with an ever increasing numeric suffix would be attempted until a free username was found. In case of a large number of existing users, this could result in many queries being executed before a free username would be found, potentially resulting in a denial of service. The new algorithm uses a random suffix and only one query to determine the final username.
Added a new setting: ACCOUNT_PRESERVE_USERNAME_CASING. This setting determines whether the username is stored in lowercase (False) or whether its casing is to be preserved (True). Note that when casing is preserved, potentially expensive __iexact lookups are performed when filter on username. For now, the default is set to True to maintain backwards compatibility.
The OAuth2Adapter class has gained a get_callback_url method for when customizing the callback URL is desired.
The Battle.net login backend now accepts the region GET parameter.
New providers: 500px, Discord.

In previous versions, the DefaultAccountAdapter contained a username_regex property and accompanying error_messages['invalid_username'] validation error message. These have been removed in favor of using the regex validation already defined at the user model level. Alternatively, you can use the newly introduced ACCOUNT_USERNAME_VALIDATORS setting.
The Battle.net backend no longer overrides username regex validation. In order to use battletags as usernames, you are expected to override either the username field on your User model, or to pass a custom validator which will accept the # character using the new ACCOUNT_USERNAME_VALIDATORS setting. Such a validator is available in socialaccount.providers.battlenet.validators.BattletagUsernameValidator.