Metadata-Version: 2.4
Name: django-allauth-async
Version: 65.19.1.1
Summary: django-allauth plus allauth_async, a native-asyncio twin of its auth flows for ASGI apps. Ships the allauth package; do not install alongside django-allauth.
Author: GlitchTip contributors
Author-email: Raymond Penners <raymond.penners@intenct.nl>
License: MIT
Project-URL: Homepage, https://gitlab.com/glitchtip/django-allauth-async
Project-URL: Source, https://gitlab.com/glitchtip/django-allauth-async
Project-URL: Tracker, https://gitlab.com/glitchtip/django-allauth-async/-/issues
Project-URL: Upstream, https://codeberg.org/allauth/django-allauth
Project-URL: Upstream documentation, https://docs.allauth.org/en/latest/
Project-URL: Funding, https://github.com/sponsors/pennersr
Classifier: Development Status :: 5 - Production/Stable
Classifier: Intended Audience :: Developers
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Classifier: Environment :: Web Environment
Classifier: Topic :: Internet
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Programming Language :: Python :: 3.14
Classifier: Framework :: Django
Classifier: Framework :: Django :: 4.2
Classifier: Framework :: Django :: 5.0
Classifier: Framework :: Django :: 5.1
Classifier: Framework :: Django :: 5.2
Classifier: Framework :: Django :: 6.0
Classifier: Framework :: Django :: 6.1
Requires-Python: >=3.10
Description-Content-Type: text/x-rst
License-File: LICENSE
License-File: AUTHORS
Requires-Dist: Django>=5.2
Requires-Dist: asgiref>=3.8.1
Requires-Dist: aiohttp>=3.9
Provides-Extra: headless
Requires-Dist: pyjwt[crypto]<3,>=2.0; extra == "headless"
Provides-Extra: headless-spec
Requires-Dist: PyYAML<7,>=6; extra == "headless-spec"
Provides-Extra: idp-oidc
Requires-Dist: oauthlib<4,>=3.3.0; extra == "idp-oidc"
Requires-Dist: pyjwt[crypto]<3,>=2.0; extra == "idp-oidc"
Provides-Extra: mfa
Requires-Dist: qrcode<9,>=7.0.0; extra == "mfa"
Requires-Dist: fido2<3,>=1.1.2; extra == "mfa"
Provides-Extra: openid
Requires-Dist: python3-openid<4,>=3.0.8; extra == "openid"
Provides-Extra: saml
Requires-Dist: python3-saml<2.0.0,>=1.15.0; extra == "saml"
Provides-Extra: steam
Requires-Dist: python3-openid<4,>=3.0.8; extra == "steam"
Provides-Extra: socialaccount
Requires-Dist: oauthlib<4,>=3.3.0; extra == "socialaccount"
Requires-Dist: requests<3,>=2.0.0; extra == "socialaccount"
Requires-Dist: pyjwt[crypto]<3,>=2.0; extra == "socialaccount"
Dynamic: license-file

====================
django-allauth-async
====================

This is a fork of `django-allauth <https://codeberg.org/allauth/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
    <https://gitlab.com/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
    <https://codeberg.org/allauth/django-allauth/issues/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
    .. code-block:: sh

        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:

    .. code-block:: python

        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
    <https://docs.allauth.org/en/latest/account/adapter.html>`_ 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!
==========================

.. image:: https://codeberg.org/allauth/allauth.org/raw/commit/da3b56390e1b18eaec09b05cd89dfa7812212dfc/content/news/2024/04/website-redesign/logo-light.png
   :target: https://allauth.org
   :align: right
   :alt: django-allauth logo
   :width: 250px


.. |ci| image:: https://img.shields.io/github/actions/workflow/status/pennersr/django-allauth/ci.yml.svg
   :target: https://github.com/pennersr/django-allauth/actions
.. |pypi| image:: https://img.shields.io/pypi/v/django-allauth
   :target: https://pypi.python.org/pypi/django-allauth
.. |cov| image:: https://img.shields.io/coverallsCoverage/github/pennersr/django-allauth
   :alt: Coverage Status
   :target: https://coveralls.io/r/pennersr/django-allauth
.. |btc| image:: https://img.shields.io/badge/bitcoin-donate-yellow
   :target: https://blockchain.info/address/1AJXuBMPHkaDCNX2rwAy34bGgs7hmrePEr
.. |liberapay| image:: https://img.shields.io/liberapay/receives/pennersr
   :target: https://en.liberapay.com/pennersr
.. |pystyle| image:: https://img.shields.io/badge/code_style-pep8-green
   :target: https://www.python.org/dev/peps/pep-0008/
.. |jsstyle| image:: https://img.shields.io/badge/code_style-standard-brightgreen
   :target: http://standardjs.com
.. |editor| image:: https://img.shields.io/badge/editor-emacs-purple
   :target: https://www.gnu.org/software/emacs/
.. |i18n| image:: https://img.shields.io/weblate/progress/allauth
   :target: https://hosted.weblate.org/projects/allauth/django-allauth/
.. |pypidl| image:: https://img.shields.io/pypi/dm/django-allauth
   :target: https://pypistats.org/packages/django-allauth
   :alt: PyPI - Downloads
.. |djangodemo| image:: https://img.shields.io/badge/%E2%96%B6_demo-Django_project-red
   :target: https://django.demo.allauth.org/
   :alt: View Django Demo
.. |reactdemo| image:: https://img.shields.io/badge/%E2%96%B6_demo-React_SPA-red
   :target: https://react.demo.allauth.org/
   :alt: View React SPA Demo

|ci| |pypi| |cov| |btc| |liberapay| |pystyle| |jsstyle| |editor| |i18n| |pypidl| |djangodemo| |reactdemo|


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/

.. end-welcome

Rationale
=========

.. begin-rationale

Most existing Django apps that address the problem of social
authentication unfortunately focus only on one dimension - the social.
Most developers end up integrating another app in order to support authentication
flows that are locally generated.

This approach creates a development gap between local and social
authentication flows. It has remained an issue in spite of numerous common
scenarios that both require. For example, an email address passed along by an
OpenID provider may not be verified. Therefore, prior to hooking up
an OpenID account to a local account the email address must be
verified. This essentially is one of many use cases that mandate email
verification to be present in both worlds.

Integrating both is a humongous and tedious process. It is not as
simple as adding one social authentication app, and one
local account registration app to your ``INSTALLED_APPS`` list.

This inadequacy is the reason for this project's existence  -- to offer a fully
integrated authentication app that allows for both local and social
authentication, with flows that just work, beautifully!

.. end-rationale


Features
========

.. begin-features

**🔑 Comprehensive account functionality**
    Supports multiple authentication
    schemes (e.g. login by user name, or by email), as well as multiple
    strategies for account verification (ranging from none to mandatory email
    verification).

**👥 Social Login**
    Login using external identity providers, supporting any *Open ID Connect
    compatible* provider, many *OAuth 1.0/2.0* providers, as well as
    custom protocols such as, for example, *Telegram* authentication.

**💼 Enterprise ready**
    Supports SAML 2.0, which is often used in a B2B context.

**🕵️ Battle-tested**
    The package has been out in the open since 2010. It is in use by many
    commercial companies whose business depends on it and has hence been
    subjected to various penetration testing attempts.

**⏳Rate limiting**
    When you expose an authentication-enabled web service to
    the internet, it is important to be prepared for potential brute force
    attempts. Therefore, rate limiting is enabled out of the box.

**🔒 Private**
    Many sites leak information. For example, on many sites you can
    check whether someone you know has an account by input their email address
    into the password forgotten form, or trying to signup with it. We offer
    account enumeration prevention, making it impossible to tell whether or not
    somebody already has an account.

**🧩 Customizable**
    As a developer, you have the flexibility to customize the core functionality
    according to your specific requirements. By employing the adapter pattern, you
    can effortlessly introduce interventions at the desired points to deviate from
    the standard behavior. This level of customization empowers you to tailor the
    software to meet your unique needs and preferences.

**⚙️ Configuration**
    The required consumer keys and secrets for interacting with Facebook,
    X (Twitter) and the likes can be configured using regular settings, or, can be
    configured in the database via the Django admin. Here, optional support for
    the Django sites framework is available, which is helpful for larger
    multi-domain projects, but also allows for easy switching between a
    development (localhost) and production setup without messing with your
    settings and database.


.. end-features


Commercial Support
==================

.. begin-support

Commercial support is available. If you find certain functionality missing, or
require assistance on your project(s), please contact us: info@intenct.nl.

.. end-support
