docs/release-notes/2024.rst
65.3.1 (2024-12-25)
Headless: When using email verification by code, you could incorrectly encounter a 409 when attempting to add a new email address while logged in.
Headless: In contrast to the headed version, it was possible to remove the last 3rd party account from a user that has no usable password. Fixed.
Headless: The setting ACCOUNT_LOGIN_ON_EMAIL_CONFIRMATION was not respected,
and always assumed to be True.
65.3.0 (2024-11-30)
MFA_TOTP_TOLERANCE).65.2.0 (2024-11-08)
OIDC: You can now configure whether or not PKCE is enabled per app by
including "oauth_pkce_enabled": True in the app settings.
The OpenStreetMap provider is deprecated. You can set it up as an OpenID Connect provider instead.
A NoReverseMatch could occur when using ACCOUNT_LOGIN_BY_CODE_REQUIRED = True while ACCOUNT_LOGIN_BY_CODE_ENABLED = False, fixed.
The PasswordResetDoneView did not behave correctly when using Django's
LoginRequiredMiddleware, as it was not properly marked as
@login_not_required.
When verifying an email address by code, the success URL was hardcoded to the
email management view, instead of calling the
get_email_verification_redirect_url() adapter method.
settings.ACCOUNT_EMAIL_VERIFICATION_BY_CODE_MAX_ATTEMPTS was not
enforced, fixed. Note that the related verification endpoint will return a
409 in case the maximum limit is exceeded, as at that point the pending email
verification stage is aborted.65.1.0 (2024-10-23)
OAuth2/OIDC: When setting up multiple apps for the same provider, you can now
configure a different scope per app by including "scope": [...] in the app
settings.
Facebook login: Facebook Limited Login <https://developers.facebook.com/docs/facebook-login/limited-login>_ is now
supported via the Headless API. When you have a Limited Login JWT obtained
from the iOS SDK, you can use the Headless "provider token" flow to login with
it.
When using HEADLESS_ONLY = True together with
ACCOUNT_REAUTHENTICATION_REQUIRED = True, you could run into a
NoReverseMatch when connecting a social acount. Fixed.
In headless mode, submitting a login code when the login flow expired resulted in a 500. Fixed -- it now returns a 409.
65.0.2 (2024-09-27)
A regression occurred in the newly introduced support using
LoginRequiredMiddleware, fixed.
For email verification by link, it is not an issue if the user runs into rate limits. The reason is that the link is session independent. Therefore, if the user hits rate limits, we can just silently skip sending additional verification emails, as the previous emails that were already sent still contain valid links. This is different from email verification by code. Here, the session contains a specific code, meaning, silently skipping new verification emails is not an option, and we must block the login instead. The latter was missing, fixed.
65.0.1 (2024-09-23)
When email verification by code was used, adding additional email addresses
over at the email management page fired the email_added signal prematurely
as the email address instance was still unsaved. Fixed.
The newly introduced logic to redirect to pending login stages has now been
integrated in the RedirectAuthenticatedUserMixin so that the existing
behavior of invoking get_authenticated_redirect_url() when already
authenticated is respected.
65.0.0 (2024-09-22)
Added transparent support for Django's LoginRequiredMiddleware (new since
Django 5.1).
The usersessions app now emits signals when either the IP address or user
agent for a session changes.
Added support for signup using a passkey. See
settings.MFA_PASSKEY_SIGNUP_ENABLED.
64.2.1 (2024-09-05)
ACCOUNT_LOGIN_ON_EMAIL_CONFIRMATION = True.It was already the case that you could not enable TOTP 2FA if your account had unverified email addresses. This is necessary to stop a user from claiming email addresses and locking other users out. This safety check is now added to WebAuthn security keys as well.
In case a user signs in into an account using social account email
authentication (SOCIALACCOUNT_EMAIL_AUTHENTICATION) and the email used is
not verified, the password of the account is now wiped (made unusable) to
prevent the person that created the account (without verifying it) from
signing in.
64.2.0 (2024-08-30)
Verifying email addresses by means of a code (instead of a link) is now supported.
See settings.ACCOUNT_EMAIL_VERIFICATION_BY_CODE_ENABLED.
Added support for requiring logging in by code, so that every user logging in
is required to input a login confirmation code sent by email. See
settings.ACCOUNT_LOGIN_BY_CODE_REQUIRED.
64.1.0 (2024-08-15)
Headless: When trying to login while a user is already logged in, you now get a 409.
Limited the maximum allowed time for a login to go through the various login
stages. This limits, for example, the time span that the 2FA stage remains
available. See settings.ACCOUNT_LOGIN_TIMEOUT.
64.0.0 (2024-07-31)
The 0.x.y version numbers really did not do justice to the state of the project, and we are way past the point where a version 1.0 would be applicable. Additionally, 64 is a nice round number. Therefore, the version numbering is changed from 0.x.y to x.y.z. We will use a loose form of semantic versioning. However, please be aware that feature releases may occasionally include minor documented backwards incompatibilities. Always read the release notes before upgrading.
Added support for WebAuthn based security keys and passkey login. Note that this is currently disabled by default.
Headless: The TOTP URI is now available in the MFA activation response.
Headless: When trying to sign up while a user is already logged in, you now get a 409.
Headless: You can now alter the user data payload by overriding the newly
introduced serialize_user() adapter method.
Headless: The token strategy now allows for exposing refresh tokens and any
other information you may need (such as e.g. expires_in).
Ensured that email address, given name and family name fields are stored in the SocialAccount instance. This information was not previously saved in Amazon Cognito, Edmodo, and MediaWiki SocialAccount instances.
When multiple third-party accounts of the same provider were connected, the
third-party account connections overview did not always provide a clear
recognizable distinction between those accounts. Now, the
SocialAccount.__str__() has been altered to return the unique username or
email address, rather than a non-unique display name.
0.63.6 (2024-07-12)
js_sdk method the
login page could become vulnerable to an XSS attack.0.63.5 (2024-07-11)
__str__() of SocialToken
caused issues within the Amazon Cognito, Atlassian, JupyterHub, LemonLDAP,
Nextcloud and OpenID Connect providers. Fixed.0.63.4 (2024-07-10)
The __str__() method of the SocialToken model returned the access
token. As a consequence, logging or printing tokens otherwise would expose the
access token. Now, the method no longer returns the token. If you want to
log/print tokens, you will now have to explicitly log the token field of
the SocialToken instance.
Enumeration prevention: the behavior on the outside of an actual signup versus a signup where the user already existed was not fully identical, fixed.
0.63.3 (2024-05-31)
In HEADLESS_ONLY mode, the /accounts/<provider>/login/ URLs were still
available, fixed.
The few remaining OAuth 1.0 providers were not compatible with headless mode, fixed.
Depending on where you placed the secure_admin_login(admin.site.login)
protection you could run into circular import errors, fixed.
RelayState was used to keep track of whether or not the login flow
was IdP or SP initiated. As RelayState is a separate field, not part of
the SAMLResponse payload, it is not signed and thereby making the SAML
login flow vulnerable to CSRF/replay attacks. Now, InResponseTo is used
instead, addressing the issue for SP initiated SSO flows. IdP initiated SSO
remains inherently insecure, by design. For that reason, it is now disabled by
default. If you need to support IdP initiated SSO, you will need to opt-in to
that by adding "reject_idp_initiated_sso": False to your advanced SAML
provider settings.0.63.2 (2024-05-24)
allauth.headless now supports the is_open_for_signup() adapter method.
In case signup is closed, a 403 is returned during signup.
Connecting a third-party account in HEADLESS_ONLY mode failed if the
connections view could not be reversed, fixed.
In case a headless attempt was made to connect a third-party account that was already connected to a different account, no error was communicated to the frontend. Fixed.
When the headless provider signup endpoint was called while that flow was not pending, a crash would occur. This has been fixed to return a 409 (conflict).
Microsoft provider: the URLs pointing to the login and graph API are now configurable via the app settings.
0.63.1 (2024-05-17)
When only allauth.account was installed, you could run into an exception
stating "allauth.socialaccount not installed, yet its models are
imported.". This has been fixed.
When SOCIALACCOUNT_EMAIL_AUTHENTICATION was turned on, and a user would
connect a third-party account for which email authentication would kick in,
the connect was implicitly skipped. Fixed.
The recommendation from the documentation to protect the Django admin login
could cause an infinite redirect loop in case of
AUTHENTICATED_LOGIN_REDIRECTS. A decorator secure_admin_login() is now
offered out of the box to ensure that the Django admin is properly secured by
allauth (e.g. rate limits, 2FA).
Subpackages from the tests package were packaged, fixed.
0.63.0 (2024-05-14)
New providers: TikTok, Lichess.
Starting since version 0.62.0, new email addresses are always stored as lower case. In this version, we take the final step and also convert existing data to lower case, alter the database indices and perform lookups accordingly. Migrations are in place. For rationale, see the note about email case sensitivity in the documentation.
An official API for single-page and mobile application support is now
available, via the new allauth.headless app.
Added support for a honeypot field on the signup form. Real users do not see the field and therefore leave it empty. When bots do fill out the field account creation is silently skipped.
0.62.1 (2024-04-24)
tests package was accidentally packaged, fixed.0.62.0 (2024-04-22)
Added a dummy provider, useful for testing purposes: allauth.socialaccount.providers.dummy.
Added a new provider, Atlassian
Next URL handling been streamlined to be consistently applied. Previously, the
password reset, change and email confirmation views only supported the
success_url class-level property.
Added support for logging in by email using a special code, also known as "Magic Code Login"
Email addresses are now always stored as lower case. For rationale, see the note about email case sensitivity in the documentation.
You can now alter the state parameter that is typically passed to the
provider by overriding the new generate_state_param() adapter method.
The URLs were not "hackable". For example, while /accounts/login/ is valid
/accounts/ was not. Similarly, /accounts/social/connections/ was
valid, but /accounts/social/ resulted in a 404. This has been
addressed. Now, /accounts/ redirects to the login or email management
page, depending on whether or not the user is authenticated. All
/accounts/social/* URLs are now below /accounts/3rdparty/*, where
/accounts/social/connections is moved to the top-level
/accounts/3rdparty/. The old endpoints still work as redirects are in
place.
Added a new setting, SOCIALACCOUNT_ONLY, which when set to True,
disables all functionality with respect to local accounts.
The OAuth2 handshake was not working properly in case of
SESSION_COOKIE_SAMESITE = "Strict", fixed.
Facebook: the default Graph API version is now v19.0.
pip install django-allauth will, e.g., no longer pull in dependencies for handling
JWT. If you are using social account functionality, install using pip install "django-allauth[socialaccount]". That will install the dependencies covering
most common providers. If you are using the Steam provider, install using pip install django-allauth[socialaccount,steam].0.61.1 (2024-02-09)
RuntimeWarning that could occur when running inside an async
environment ('SyncToAsync' was never awaited).OpenID Connect Core 1.0 specification <https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation>_.
However, as django-allauth is used and built upon by third parties, this is an
implementation detail with security implications that is easily overlooked. To
mitigate potential issues, verifying the signature is now only skipped if it
was django-allauth that actually fetched the access token.0.61.0 (2024-02-07)
Added support for account related security notifications. When
ACCOUNT_EMAIL_NOTIFICATIONS = True, email notifications such as "Your
password was changed", including information on user agent / IP address from where the change
originated, will be emailed.
Google: Starting from 0.52.0, the id_token is being used for extracting
user information. To accommodate for scenario's where django-allauth is used
in contexts where the id_token is not posted, the provider now looks up
the required information from the /userinfo endpoint based on the access
token if the id_token is absent.
MFA_TOTP_PERIOD)."5/m" it was handled implicitly whether or not that limit was per IP,
per user, or per action specific key. This has now been made explicit:
"5/m/user" vs "5/m/ip" vs "5/m/key". Combinations are also supported
now: "20/m/ip,5/m/key" . Additionally, the rate limit mechanism is now used
throughout, including email confirmation cooldown as well as limitting failed login
attempts. Therefore, the ACCOUNT_LOGIN_ATTEMPTS_LIMIT and
ACCOUNT_EMAIL_CONFIRMATION_COOLDOWN settings are deprecated.
See :doc:Rate Limits <../account/rate_limits> for details.0.60.1 (2024-01-15)
User sessions: after changing your password in case of ACCOUNT_LOGOUT_ON_PASSWORD_CHANGE = False, the list of
sessions woud be empty instead of showing your current session.
SAML: accessing the SLS/ACS views using a GET request would result in a crash (500).
SAML: the login view did not obey the SOCIALACCOUNT_LOGIN_ON_GET = False setting.
__iexact lookups). The latter requires case insensitive
index support, which not all databases support. Re-evaluating the approach in
current times has led to the conclusion that the benefits do not outweigh the
costs. Therefore, email addresses are now always stored as lower case, and
migrations are in place to address existing records.0.60.0 (2024-01-05)
Google One Tap Sign-In is now supported.
You can now more easily change the URL to redirect to after a successful password
change/set via the newly introduced get_password_change_redirect_url()
adapter method.
You can now configure the primary key of all models by configuring
ALLAUTH_DEFAULT_AUTO_FIELD, for example to:
"hashid_field.HashidAutoField".
You can now specify the URL path prefix that is used for all OpenID Connect
providers using SOCIALACCOUNT_OPENID_CONNECT_URL_PREFIX. By default, it is
set to "oidc", meaning, an OpenID Connect provider with provider ID
foo uses /accounts/oidc/foo/login/ as its login URL. Set it to empty
("") to keep the previous URL structure (/accounts/foo/login/).
The SAML default attribute mapping for uid has been changed to only
include urn:oasis:names:tc:SAML:attribute:subject-id. If the SAML response
does not contain that, it will fallback to use NameID.