Fincity-django-allauth

Latest version: v0.40.0

Safety actively analyzes 629599 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 3 of 9

0.30.0

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

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

- 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.


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

- 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``.

0.29.0

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

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

- Addressed Django 1.10 deprecation warnings.

0.28.0

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

Security notice
---------------

- Previous versions contained a vulnerability allowing an attacker to alter the
provider specific settings for ``SCOPE`` and/or ``AUTH_PARAMS`` (part of the
larger ``SOCIALACCOUNT_PROVIDERS`` setting). The changes would persist across
subsequent requests for all users, provided these settings were explicitly set
within your project. These settings translate directly into request
parameters, giving the attacker undesirable control over the OAuth(2)
handshake. You are not affected if you did not explicitly configure these
settings. Thanks to Ryan Kelly for reporting!


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

- New providers: Doximity.

- New translations: Korean.

0.27.0

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

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

- Django 1.10 compatibility.

- The Twitter and GitHub providers now support querying of the email address.


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

- When ``ACCOUNT_SIGNUP_EMAIL_ENTER_TWICE`` was turned on, the e-mail field key
changed from ``email`` to ``email1``, which could introduce subtle bugs. This
has now been changed: there always is an ``email`` field, and optionally an
``email2`` field.

- The "You must type the same password each time" form validation error that can
be triggered during signup is now added to the ``password2`` field instead of
being added to the non field errors.

- The ``email_confirmation_sent`` signal is now passed ``request``,
``confirmation`` and ``signup`` instead of only the ``confirmation``.

- ``ACCOUNT_PASSWORD_MIN_LENGTH`` was already deprecated, but is now completely
ignored if ``AUTH_PASSWORD_VALIDATORS`` is not empty.

0.26.1

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

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

- Locale files wrongly packaged, fixed.

- Fixed bug (``KeyError``) when ``ACCOUNT_SIGNUP_EMAIL_ENTER_TWICE`` was set to
``True``.

0.26.0

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

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

- New providers: Weixin, Battle.net, Asana, Eve Online, 23andMe, Slack

- Django's password validation mechanism (see ``AUTH_PASSWORD_VALIDATORS``) is now
used to validate passwords.

- By default, email confirmations are no longer stored in the
database. Instead, the email confirmation mail contains an HMAC
based key identifying the email address to confirm. The verification
lookup includes a fallback to the previous strategy so that there is
no negative impact on pending verification emails.

- A new setting ``ACCOUNT_SIGNUP_EMAIL_ENTER_TWICE`` was added, requiring users to
input their email address twice. The setting
``ACCOUNT_SIGNUP_PASSWORD_VERIFICATION`` has been renamed to
``ACCOUNT_SIGNUP_PASSWORD_ENTER_TWICE``.

- New translations: Latvian, Kyrgyz.


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

- Dropped support for Django 1.6

- In order to accomodate for Django's password validation, the
``clean_password`` method of the adapter now takes an (optional)
``user`` parameter as its second argument.

- The new HMAC based keys may contain colons. If you have forked
``account/urls.py``, be sure to sync the ``account_confirm_email``
pattern.

Page 3 of 9

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.