Metadata-Version: 2.4
Name: django-allauth-async
Version: 65.16.1.6
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
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 and running into
    known ASGI issues (upstream issues `#3566
    <https://github.com/pennersr/django-allauth/issues/3566>`_, `#3634
    <https://github.com/pennersr/django-allauth/issues/3634>`_). Upstream has
    no async roadmap; this fork exists to build one — with the intent of
    proposing the design upstream once it has stabilized in production.

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.

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``. The async layer is enabled by swapping specific entry
    points to their ``allauth_async`` counterparts (middleware, authentication
    backend, and the headless/provider URL includes); see the
    ``allauth_async`` module docstrings until dedicated docs land here.

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
