Fincity-django-allauth

*******************

Note worthy changes
-------------------

- Reversal of the email confirmation url can now be overridden in
the adapter (``get_email_confirmation_url``). Additionally, the
complete confirmation email handling can be overridden via
``send_confirmation_mail``.

- Template context processors are no longer used.

- The Facebook Graph API fields (/me/?fields=...) can now be
configured using the provider ``FIELDS`` setting.


Backwards incompatible changes
------------------------------

- Dropped support for Python 2.6 and Django <1.6.

- The default Facebook Graph API version is now v2.4.

- Template context processors are no longer used. The context
processor for ``allauth.account`` was already empty, and the context
processor for ``allauth.socialaccount`` has been converted into the
:doc:``{% get_providers %} <templates>`` template tag.

*******************

Note worthy changes
-------------------

- You can now tweak the authentication params per OAuth provider,
as you already could for OAuth2. Contributed by Peter Rowlands,
thanks.

- Nattaphoom Ch. contributed a Thai translation, thanks!

- Guoyu Hao contributed a Baidu provider, thanks!

- Rod Xavier Bondoc contributed support logging out on password
change (see setting: ``ACCOUNT_LOGOUT_ON_PASSWORD_CHANGE``)


Backwards incompatible changes
------------------------------

- In version 0.20.0 an ``account`` migration (``0002_email_max_length``)
was added to alter the maximum length of the email
field. Unfortunately, a side effect of this migration was that the
``unique=True`` setting slipped through as well. Hardcoding this to
``True`` is wrong, as uniqueness actually depends on the
``ACCOUNT_UNIQUE_EMAIL`` setting. We cannot create a followup ``0003``
migration to set things straight, as the ``0002`` migration may fail
on installations where email addresses are not unique. Therefore, we
had to resort to changing an existing migration which is normally
not the right thing to do. In case your installation has
``ACCOUNT_UNIQUE_EMAIL`` set to ``True``, you need not take any further
action. In case it is set to ``False`` and migration ``0002`` already
ran, please issue a ``--fake`` migration down to ``0001``, followed by a
re-run of the updated ``0002``.

*******************

Note worthy changes
-------------------

- Patrick Paul contributed a provider for Evernote, thanks!

- Josh Wright contributed a provider for Spotify, thanks!

- Björn Andersson added support for Dropbox OAuth2, thanks!

- guoqiao contributed a provider for Douban, thanks!


Backwards incompatible changes
------------------------------

- Given that the ``max_length`` for the Django 1.8 ``EmailField`` has been
bumped to 254, allauth is following up. Migrations (``account``) are
in place.

*******************

Note worthy changes
-------------------

- Fixed migrations when using South & Django 1.6.

*******************

Note worthy changes
-------------------

- Basil Shubin contributed an Odnoklassniki provider, thanks!

- Facebook: If the JS SDK is not available, for example due to a
browser plugin like Disconnect.me that blocks it, login falls back
to the regular non JS handshake.

- ``is_safe_url`` can now be overriden

- Facebook: The Graph API version is now configurable via
``SOCIALACCOUNT_PROVIDERS``.

- A Firefox Accounts provider was added by Jannis Leidel, thanks!

- Josh Owen contributed Coinbase support, thanks!

- Tomas Babej contributed a Slovak translation, thanks!

- Moved existing migrations into ``south_migrations``

- "zbryikt" contributed a Taiwanese Chinese translation, thanks!

- Added support for custom password rules via ``clean_password``.


Backwards incompatible changes
------------------------------

- In the upcoming Django 1.8 it is no longer possible to hookup an
unsaved ``User`` instance to a ``SocialAccount``. Therefore, if you are
inspecting the ``sociallogin`` object, you should now use
``sociallogin.user`` instead of ``sociallogin.account.user``.

- When users logged in while ``User.is_active`` was ``False``, they were
sent to ``/accounts/inactive/`` in case of a social login, and
received a form validation error in case of a local login. This
needless inconsistency has been removed. The validation error no
longer appears and local logins are also redirected to
``/accounts/inactive/``.

- In case you were overriding the ``ResetPasswordForm``: the save method
now takes ``request`` as its first argument.

- All existing migrations have been moved into ``south_migrations``
packages, this in order not to conflict with Django's built-in
support for migrations. South 1.0 automatically picks up this new
location. Upgrade South if you are still dependent on these
migrations.

*******************

Note worthy changes
-------------------

- Storing social access tokens is now optional
(``SOCIALACCOUNT_STORE_TOKENS``).

- ``nimiq`` contributed ORCID support, thanks.

- All forms are now pluggable via a new setting:
``(SOCIAL)ACCOUNT_FORMS``.

- James Thompson contributed Windows Live support, thanks!


Backwards incompatible changes
------------------------------

- SECURITY: The Persona provider now requires the ``AUDIENCE`` parameter
to be explicitly configured, as required by the Persona
specification for security reasons.

- The inline Javascript is removed from the ``fbconnect.html`` template,
which allows for a more strict ``Content-Security-Policy``. If you
were using the builtin ``fbconnect.html`` this change should go by
unnoticed.