django-allauth-async 65.19.1.1

django-allauth-async

This is a fork of django-allauth (MIT licensed, by Raymond Penners and contributors) that adds allauth_async: a native-asyncio twin of allauth’s authentication flows for ASGI applications.

Why fork?

django-allauth is sync throughout — sync ORM in its flows, sync signal dispatch, blocking requests calls for OAuth/OIDC, and sync headless views. An async-first ASGI application (such as GlitchTip) can only call it through sync_to_async, paying a thread hop per auth request. Async support was proposed upstream and declined (Interest in async support? #3546) — an understandable call for a project of allauth’s scope, since it means maintaining an async twin of nearly every interface. This fork takes on exactly that burden so that async-first applications don’t have to wait. It is a friendly fork: where a change stands on its own we still offer it upstream, and if upstream ever decides to pursue async support, the intent is to contribute this work and wind the fork down.

How it relates to upstream

The allauth package in this repository is unmodified upstream code at the version this fork is based on (see the release tag). All fork code is additive, inside allauth_async/: each of its modules mirrors one upstream module and re-implements the blocking parts with real asyncio — async ORM, auth.alogin/aauthenticate, Signal.asend, async sessions, and aiohttp for outbound HTTP. A drift manifest (allauth_async/_upstream_manifest.json) records the reviewed hash of every mirrored upstream file; CI fails after an upstream merge until the affected async twins are re-reviewed (scripts/check_drift.py / scripts/ack_drift.py). Non-additive changes to upstream files are avoided; if one is ever unavoidable it carries [patch-upstream] in the commit subject so git log --grep='\[patch-upstream\]' lists the entire conflict surface.

Compatibility — ASGI only

The allauth_async components (middleware, authentication backend, async views/URLs, adapters) require an ASGI deployment and Django 5.2+ (for aauthenticate/alogin), and are tested only under ASGI. They exist to serve auth natively on the event loop; under WSGI they would only add overhead over plain django-allauth, so that combination is unsupported. If you deploy with WSGI, use upstream django-allauth instead. Code that touches only allauth.* behaves exactly like upstream — it is upstream — under WSGI or ASGI alike, but then this fork buys you nothing over the original.

Versioning

<upstream version>.<fork iteration> — e.g. 65.16.1.2 is the second fork release based on upstream 65.16.1. Upstream updates are merged (never rebased) from the upstream tag.

Installation

pip install django-allauth-async

Do not install alongside django-allauth — this distribution ships the allauth package itself, and the two would overwrite each other. allauth_async refuses to import if both are present.

Upstream’s documentation at https://docs.allauth.org applies to everything under allauth.

Using the async layer

Swap these entry points for their allauth_async counterparts; everything else (settings, templates, flows) follows upstream’s documentation:

MIDDLEWARE = [
    # ... instead of allauth.account.middleware.AccountMiddleware:
    "allauth_async.account.middleware.AsyncAccountMiddleware",
]
AUTHENTICATION_BACKENDS = (
    "allauth_async.account.auth_backends.AsyncAuthenticationBackend",
)
ACCOUNT_ADAPTER = "allauth_async.account.adapter.AsyncDefaultAccountAdapter"
SOCIALACCOUNT_ADAPTER = (
    "allauth_async.socialaccount.adapter.AsyncDefaultSocialAccountAdapter"
)
MFA_ADAPTER = "allauth_async.mfa.adapter.AsyncDefaultMFAAdapter"
HEADLESS_ADAPTER = "allauth_async.headless.adapter.AsyncDefaultHeadlessAdapter"

urlpatterns = [
    path("accounts/", include("allauth_async.urls")),
    path("_allauth/", include("allauth_async.headless.urls")),
]

Customizing adapters

The async adapters subclass their upstream counterparts, and upstream’s adapter documentation still defines each hook’s semantics. What changes is which method the async flows call. An I/O-bearing hook foo() has a native-async twin afoo() (asend_mail, asave_user, aauthenticate, ais_email_verified, …) and the async flows call the twin — an override of the sync method alone will not run on async request paths. Pure-computation hooks (clean_*, render_mail, get_from_email, the redirect-URL getters, …) either have no twin or a twin that delegates to the sync method, so existing sync overrides keep working — unless the override itself does database or network I/O, in which case override the twin as well. The Async*Adapter classes (e.g. AsyncAccountAdapterMixin in allauth_async/account/adapter.py) are the authoritative list of twins; each docstring states whether it delegates to its sync hook.

Everything below this line is the original django-allauth README.

Welcome to django-allauth!

Integrated set of Django applications addressing authentication, registration, account management as well as 3rd party (social) account authentication.

Home page

https://allauth.org/

Source code

https://codeberg.org/allauth/django-allauth

Issue Tracker

https://codeberg.org/allauth/django-allauth/issues

Documentation

https://docs.allauth.org/en/latest/

Stack Overflow

https://stackoverflow.com/questions/tagged/django-allauth

Demo

https://django.demo.allauth.org and https://react.demo.allauth.org

Translations

https://hosted.weblate.org/projects/allauth/django-allauth/