head 1.24; access; symbols pkgsrc-2026Q2:1.24.0.6 pkgsrc-2026Q2-base:1.24 pkgsrc-2026Q1:1.24.0.4 pkgsrc-2026Q1-base:1.24 pkgsrc-2025Q4:1.24.0.2 pkgsrc-2025Q4-base:1.24 pkgsrc-2025Q3:1.22.0.2 pkgsrc-2025Q3-base:1.22 pkgsrc-2025Q2:1.21.0.2 pkgsrc-2025Q2-base:1.21 pkgsrc-2025Q1:1.18.0.2 pkgsrc-2025Q1-base:1.18 pkgsrc-2024Q4:1.15.0.2 pkgsrc-2024Q4-base:1.15 pkgsrc-2024Q3:1.13.0.2 pkgsrc-2024Q3-base:1.13 pkgsrc-2024Q2:1.12.0.2 pkgsrc-2024Q2-base:1.12 pkgsrc-2024Q1:1.8.0.2 pkgsrc-2024Q1-base:1.8 pkgsrc-2023Q4:1.5.0.2 pkgsrc-2023Q4-base:1.5 pkgsrc-2023Q3:1.3.0.2 pkgsrc-2023Q3-base:1.3 pkgsrc-2023Q2:1.1.0.2 pkgsrc-2023Q2-base:1.1; locks; strict; comment @# @; 1.24 date 2025.12.10.17.49.29; author adam; state Exp; branches; next 1.23; commitid M7dFCJcy5h3S9TlG; 1.23 date 2025.11.17.08.42.23; author adam; state Exp; branches; next 1.22; commitid LQoF3OpJv5f2SSiG; 1.22 date 2025.07.10.15.53.45; author adam; state Exp; branches; next 1.21; commitid 0sAimbqlQwU4rd2G; 1.21 date 2025.05.22.05.37.49; author adam; state Exp; branches; next 1.20; commitid dnpKD6HNA1arBRVF; 1.20 date 2025.05.12.13.05.52; author adam; state Exp; branches; next 1.19; commitid ML4MQrIUMsA4pCUF; 1.19 date 2025.04.14.18.37.05; author adam; state Exp; branches; next 1.18; commitid X6gnfLEl9ELr83RF; 1.18 date 2025.02.07.15.07.59; author adam; state Exp; branches; next 1.17; commitid vuegpP5YCoik6yIF; 1.17 date 2025.02.06.16.22.38; author adam; state Exp; branches; next 1.16; commitid qTE24hT9ACeVxqIF; 1.16 date 2025.02.04.10.18.11; author adam; state Exp; branches; next 1.15; commitid Bb6uSujUMRIRA8IF; 1.15 date 2024.11.11.07.29.17; author wiz; state Exp; branches; next 1.14; commitid 1fBDq3LwS98NncxF; 1.14 date 2024.10.14.06.46.06; author wiz; state Exp; branches; next 1.13; commitid ynDJEEQamKd33BtF; 1.13 date 2024.07.17.09.12.54; author adam; state Exp; branches; next 1.12; commitid oZRd9STk6NT1JaiF; 1.12 date 2024.06.10.07.28.52; author adam; state Exp; branches; next 1.11; commitid MHsuCJZdsxx2lpdF; 1.11 date 2024.05.24.16.53.14; author adam; state Exp; branches; next 1.10; commitid 4mCzWKo8n50C0hbF; 1.10 date 2024.05.18.06.10.53; author adam; state Exp; branches; next 1.9; commitid ERejUgiCSDI9EraF; 1.9 date 2024.05.06.08.08.40; author adam; state Exp; branches; next 1.8; commitid hlYPKNFlVYtvGU8F; 1.8 date 2024.02.11.19.47.46; author adam; state Exp; branches; next 1.7; commitid taACvNdGRIOIh3YE; 1.7 date 2024.02.08.14.01.00; author adam; state Exp; branches; next 1.6; commitid vjXIRFezcDkKsDXE; 1.6 date 2024.02.01.10.31.58; author adam; state Exp; branches; next 1.5; commitid wINTWwN99HyZwIWE; 1.5 date 2023.12.02.07.26.21; author adam; state Exp; branches; next 1.4; commitid xSogLKtTr9xSsROE; 1.4 date 2023.11.07.22.38.09; author wiz; state Exp; branches; next 1.3; commitid 0SUcCzviRXnrjJLE; 1.3 date 2023.08.31.17.36.13; author adam; state Exp; branches; next 1.2; commitid qLjxKhnM3RVqPXCE; 1.2 date 2023.08.30.13.52.00; author adam; state Exp; branches; next 1.1; commitid 85tPc5UQ3gwuCOCE; 1.1 date 2023.06.04.02.29.21; author markd; state Exp; branches; next ; commitid TqOUB4duzeozDzrE; desc @@ 1.24 log @py-django-allauth: updated to 65.13.1 65.13.1 Note worthy changes - Django 6.0 is now officially supported. Fixes - Internal imports related to headless token strategies were causing (harmless) deprecation warnings, fixed. - Pending social signups stored in the session by allauth versions prior to 65.5.0 are not resumable by newer versions. This could cause 500s while upgrading, fixed. - Headless: the reauthentication-required response in the OpenAPI specification was wrongly nested and did not match the actual implementation, fixed. @ text @# $NetBSD: Makefile,v 1.23 2025/11/17 08:42:23 adam Exp $ DISTNAME= django_allauth-65.13.1 PKGNAME= ${PYPKGPREFIX}-${DISTNAME:S/_/-/} CATEGORIES= www python MASTER_SITES= ${MASTER_SITE_PYPI:=d/django-allauth/} MAINTAINER= pkgsrc-users@@NetBSD.org HOMEPAGE= https://github.com/pennersr/django-allauth COMMENT= Authentication, registration, account mgmt and 3rd party account auth LICENSE= mit TOOL_DEPENDS+= ${PYPKGPREFIX}-setuptools>=78:../../devel/py-setuptools DEPENDS+= ${PYPKGPREFIX}-asgiref>=3.8.1:../../www/py-asgiref DEPENDS+= ${PYPKGPREFIX}-django>=4.2.16:../../www/py-django # openid DEPENDS+= ${PYPKGPREFIX}-openid>=3.0.8:../../security/py-openid # socialaccount DEPENDS+= ${PYPKGPREFIX}-JWT>=2.0:../../textproc/py-JWT DEPENDS+= ${PYPKGPREFIX}-oauthlib>=3.3.0:../../security/py-oauthlib DEPENDS+= ${PYPKGPREFIX}-requests>=2.0.0:../../devel/py-requests USE_LANGUAGES= # none .include "../../lang/python/wheel.mk" .include "../../mk/bsd.pkg.mk" @ 1.23 log @py-django-allauth: updated to 65.13.0 65.13.0 (2025-10-31) ******************** Note worthy changes ------------------- - IdP: Added support for RP-Initiated Logout. - Headless: added JWT token strategy. - Added support for "Trust this browser?" functionality for logging in by code. See ``ACCOUNT_LOGIN_BY_CODE_TRUST_ENABLED``. - OpenID Connect: to avoid issues with client IDs containing colons, ``client_secret_post`` is now preferred above ``client_secret_basic``. Security notice --------------- - Both Okta and NetIQ were using ``preferred_username`` as the identifier for third-party provider accounts. That value may be mutable and should therefore be avoided for authorization decisions. The providers are now using ``sub`` instead. - IdP: marking a user as ``is_active=False`` after having handed tokens for that user while the account was still active had no effect. Fixed -- the access/refresh tokens are now rejected. Thanks to Joshua Rogers for reporting this and the previous issue. Backwards incompatible changes ------------------------------ - Headless now requires the ``headless`` extra to be installed. For example: ``pip install django-allauth[headless]``. - Okta and NetIQ: see the security notice on Okta and NetIQ. Already existing ``SocialAccount`` records will no longer be linked due to the switch to ``sub``. You will need to manually handle this situation either, by populating ``SocialAccount.uid`` based on ``sub`` located in ``SocialAccount.extra_data``,or, if you are absolutely certain the security notice is of no concern for your use case, by setting ``"uid_field": "preferred_username"`` in the relevant ``SocialApp.settings``. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.22 2025/07/10 15:53:45 adam Exp $ d3 1 a3 1 DISTNAME= django_allauth-65.13.0 @ 1.22 log @py-django-allauth: updated to 65.10.0 65.10.0 (2025-07-10) Note worthy changes - IdP: Added support for the device authorization grant. - Headless: custom user payloads can now be properly reflected in the OpenAPI specification by provider a user ``dataclass``. See the newly introduced ``get_user_dataclass()`` and ``user_as_dataclass()`` adapter methods. - Added a new signal (``authentication_step_completed``) that is emitted when an individual authentication step is completed. - MFA: Added a setting (``MFA_ALLOW_UNVERIFIED_EMAIL``) to allow unverified email addresses in combination with MFA. Backwards incompatible changes - Soundcloud: as per https://developers.soundcloud.com/blog/urn-num-to-string, the provider now uses the user ``urn`` instead of the ``id`` as the ID for social accounts. This change is backward incompatible. Instructions on how to migrate existing social accounts can be found in the allauth provider documentation for SoundCloud. Fixes - Phone: The recently added support for phone (SMS) authentication did fully integrate with third-party provider signups. For example, whether or not the phone number is required was not respected during signup. Fixed. - IdP: Token revocation failed when a single ``token_type_hint`` was passed, fixed. - The ``verified_email_required`` decorator did not support email verification by code. Additionally, it did not rate limit verification emails in case of GET requests. Both are fixed. - The account adapter ``clean_email()`` method was not called when a social account auto signup took place, fixed. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.21 2025/05/22 05:37:49 adam Exp $ d3 1 a3 1 DISTNAME= django_allauth-65.10.0 d19 2 a20 1 DEPENDS+= ${PYPKGPREFIX}-JWT>=1.7:../../textproc/py-JWT a21 1 DEPENDS+= ${PYPKGPREFIX}-requests-oauthlib>=0.3.0:../../security/py-requests-oauthlib @ 1.21 log @py-django-allauth: updated to 65.8.1 65.8.1 (2025-05-21) Fixes - Fixed a compatibility issue with the newly released fido2 2.0.0 package. Security notice - After a successful login, the rate limits for that login were cleared, allowing a succesful login on a specific IP address to be used as a means to clear the login failed rate limit for that IP address. Fixed. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.20 2025/05/12 13:05:52 adam Exp $ d3 1 a3 1 DISTNAME= django_allauth-65.8.1 @ 1.20 log @py-django-allauth: updated to 65.8.0 65.8.0 (2025-05-08) Note worthy changes - Fixed VK (a.k.a VK ID) social account provider. Improved its documentation. - Added optional support for requesting new email/phone verification codes during signup. See ``ACCOUNT_EMAIL_VERIFICATION_SUPPORTS_RESEND`` and ``ACCOUNT_PHONE_VERIFICATION_SUPPORTS_RESEND``. - Added optional support for changing your email or phone at the verification stage while signing up. See ``ACCOUNT_EMAIL_VERIFICATION_SUPPORTS_CHANGE`` and ``ACCOUNT_PHONE_VERIFICATION_SUPPORTS_CHANGE``. - Added support for Mailcow OAuth2. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.19 2025/04/14 18:37:05 adam Exp $ d3 1 a3 1 DISTNAME= django_allauth-65.8.0 @ 1.19 log @py-django-allauth: updated to 65.7.0 65.7.0 (2025-04-03) Note worthy changes - Officially support Django 5.2. - Headless: the URL to the OpenID configuration of the provider is now exposed in the provider config. Fixes - Headless: when multiple login methods were enabled (e.g. both username and email), the login endpoint would incorrectly return a 400 ``invalid_login``. Fixed. 65.6.0 (2025-03-27) Note worthy changes - MFA: Added support for "Trust this browser?" functionality, which presents users with MFA enabled the choice to trust their browser allowing them to skip authenticating per MFA on each login. Fixes - A check is in place to verify that ``ACCOUNT_LOGIN_METHODS`` is aligned with ``ACCOUNT_SIGNUP_FIELDS``. The severity level of that check has now been lowered from "critical" to "warning", as there may be valid use cases for configuring a login method that you are not able to sign up with. This check (``account.W001``) can be silenced using Django's ``SILENCED_SYSTEM_CHECKS``. - The setting ``ACCOUNT_LOGIN_ON_PASSWORD_RESET = True`` was not respected when using password reset by code. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.18 2025/02/07 15:07:59 adam Exp $ d3 1 a3 1 DISTNAME= django_allauth-65.7.0 @ 1.18 log @py-django-allauth: updated to 65.4.1 65.4.1 (2025-02-07) Fixes - To make way for a future ``"phone"`` method, ``AUTHENTICATION_METHOD`` was removed in favor of a new ``LOGIN_METHODS``. While this change was done in a backwards compatible manner within allauth scope, other packages accessing ``allauth.account.app_settings.AUTHENTICATION_METHOD`` would break. Fixed. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.17 2025/02/06 16:22:38 adam Exp $ d3 1 a3 1 DISTNAME= django_allauth-65.4.1 d13 1 a13 1 TOOL_DEPENDS+= ${PYPKGPREFIX}-setuptools>=40.8.0:../../devel/py-setuptools @ 1.17 log @py-django-allauth: updated to 65.4.0 65.4.0 (2025-02-06) Note worthy changes - The setting ``ACCOUNT_AUTHENTICATION_METHOD: str`` (with values ``"username"``, ``"username_email"``, ``"email"``) has been replaced by ``ACCOUNT_LOGIN_METHODS: set[str]``. which is a set of values including ``"username"`` or ``"email"``. This change is performed in a backwards compatible manner. - Headless: when ``HEADLESS_SERVE_SPECIFICATION`` is set to ``True``, the API specification will be served dynamically, over at ``/_allauth/openapi.(yaml|json|html)``. The ``HEADLESS_SPECIFICATION_TEMPLATE_NAME`` can be configured to choose between Redoc (``"headless/spec/redoc_cdn.html"``) and Swagger ( (``"headless/spec/swagger_cdn.html"``). - Headless: added a new setting, ``HEADLESS_CLIENTS`` which you can use to limit the types of API clients (app/browser). - Headless: expanded the React SPA example to showcase integration with Django Ninja as well as Django REST framework. - Headless: added out of the box support for being able to use the headless session tokens with Django Ninja and Django REST framework. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.16 2025/02/04 10:18:11 adam Exp $ d3 1 a3 1 DISTNAME= django_allauth-65.4.0 @ 1.16 log @py-django-allauth: updated to 65.3.1 65.3.1 (2025-12-25) ******************* Fixes ----- - 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) ******************* Note worthy changes ------------------- - Added support for TOTP code tolerance (see ``MFA_TOTP_TOLERANCE``). Security notice --------------- - Authentication by email/password was vulnerable to account enumeration by means of a timing attack. Thanks to Julie Rymer for the report and the patch. 65.2.0 (2024-11-08) ******************* Note worthy changes ------------------- - 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. Fixes ----- - 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. Security notice --------------- - Headless: ``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. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.15 2024/11/11 07:29:17 wiz Exp $ d3 1 a3 1 DISTNAME= django_allauth-65.3.1 d9 1 a9 1 HOMEPAGE= https://github.com/pennersr/django-allauth/ @ 1.15 log @py-*: remove unused tool dependency py-setuptools includes the py-wheel functionality nowadays @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.14 2024/10/14 06:46:06 wiz Exp $ d3 1 a3 1 DISTNAME= django_allauth-0.63.6 d14 5 a19 2 DEPENDS+= ${PYPKGPREFIX}-django>=3.2:../../www/py-django DEPENDS+= ${PYPKGPREFIX}-openid>=3.0.8:../../security/py-openid @ 1.14 log @*: clean-up after python38 removal @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.13 2024/07/17 09:12:54 adam Exp $ a13 1 TOOL_DEPENDS+= ${PYPKGPREFIX}-wheel-[0-9]*:../../devel/py-wheel @ 1.13 log @py-django-allauth: updated to 0.63.6 0.63.6 (2024-07-12) ******************* Security notice --------------- - When the Facebook provider was configured to use the ``js_sdk`` method the login page could become vulnerable to an XSS attack. 0.63.5 (2024-07-11) ******************* Fixes ----- - The security fix in 0.63.4 that altered the ``__str__()`` of ``SocialToken`` caused issues within the Amazon Cognito, Atlassian, JupyterHub, LemonLDAP, Nextcloud and OpenID Connect providers. Fixed. 0.63.4 (2024-07-10) ******************* Security notice --------------- - 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. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.12 2024/06/10 07:28:52 adam Exp $ a22 2 PYTHON_VERSIONS_INCOMPATIBLE= 27 38 @ 1.12 log @py-django-allauth: updated to 0.63.3 0.63.3 (2024-05-31) ******************* Note worthy changes ------------------- - In ``HEADLESS_ONLY`` mode, the ``/accounts//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. Backwards incompatible changes ------------------------------ - SAML: IdP initiated SSO is disabled by default, see security notice below. Security notice --------------- - SAML: ``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. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.11 2024/05/24 16:53:14 adam Exp $ d3 1 a3 1 DISTNAME= django_allauth-0.63.3 @ 1.11 log @py-django-allauth: updated to 0.63.2 0.63.2 (2024-05-24) ******************* Note worthy changes ------------------- - ``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. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.10 2024/05/18 06:10:53 adam Exp $ d3 2 a4 2 DISTNAME= django-allauth-0.63.2 PKGNAME= ${PYPKGPREFIX}-${DISTNAME} @ 1.10 log @py-django-allauth: updated to 0.63.1 0.63.1 (2024-05-17) ******************* Note worthy changes ------------------- - 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) ******************* Note worthy changes ------------------- - 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. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.9 2024/05/06 08:08:40 adam Exp $ d3 1 a3 1 DISTNAME= django-allauth-0.63.1 @ 1.9 log @py-django-allauth: updated to 0.62.1 0.62.1 (2024-04-24) ******************* - The ``tests`` package was accidentally packaged, fixed. 0.62.0 (2024-04-22) ******************* Note worthy changes ------------------- - 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. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.8 2024/02/11 19:47:46 adam Exp $ d3 1 a3 1 DISTNAME= django-allauth-0.62.1 @ 1.8 log @py-django-allauth: updated to 0.61.1 0.61.1 (2024-02-09) ******************* Fixes ----- - Fixed a ``RuntimeWarning`` that could occur when running inside an async environment (``'SyncToAsync' was never awaited``). Security notice --------------- - As part of the Google OAuth handshake, an ID token is obtained by direct machine to machine communication between the server running django-allauth and Google. Because of this direct communication, we are allowed to skip checking the token signature according to the `OpenID Connect Core 1.0 specification `_. 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. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.7 2024/02/08 14:01:00 adam Exp $ d3 1 a3 1 DISTNAME= django-allauth-0.61.1 d13 1 a13 1 TOOL_DEPENDS+= ${PYPKGPREFIX}-setuptools>-40.8.0:../../devel/py-setuptools @ 1.7 log @py-django-allauth: updated to 0.61.0 0.61.0 (2024-02-07) ******************* Note worthy changes ------------------- - 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. Security notice --------------- - MFA: It was possible to reuse a valid TOTP code within its time window. This has now been addressed. As a result, a user can now only login once per 30 seconds (``MFA_TOTP_PERIOD``). Backwards incompatible changes ------------------------------ - The rate limit mechanism has received an update. Previously, when specifying e.g. ``"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. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.6 2024/02/01 10:31:58 adam Exp $ d3 1 a3 1 DISTNAME= django-allauth-0.61.0 @ 1.6 log @py-django-allauth: updated to 0.60.1 0.60.1 (2024-01-15) ******************* Fixes ----- - 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. 0.60.0 (2024-01-05) ******************* Note worthy changes ------------------- - 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"``. Backwards incompatible changes ------------------------------ - 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``. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.5 2023/12/02 07:26:21 adam Exp $ d3 1 a3 1 DISTNAME= django-allauth-0.60.1 @ 1.5 log @py-django-allauth: updated to 0.58.2 0.58.0 (2023-10-26) ******************* Note worthy changes ------------------- - The ``SocialAccount.exra_data`` field was a custom JSON field that used ``TextField`` as the underlying implementation. It was once needed because Django had no ``JSONField`` support. Now, this field is changed to use the official ``JSONField()``. Migrations are in place. - Officially support Django 5.0. - In previous versions, users could never remove their primary email address. This is constraint is now relaxed. In case the email address is not required, for example, because the user logs in by username, removal of the email address is allowed. - Added a new setting ``ACCOUNT_REAUTHENTICATION_REQUIRED`` that, when enabled, requires the user to reauthenticate before changes (such as changing the primary email address, adding a new email address, etc.) can be performed. Backwards incompatible changes ------------------------------ - Refactored the built-in templates, with the goal of being able to adjust the look and feel of the whole project by only overriding a few core templates. This approach allows you to achieve visual results fast, but is of course more limited compared to styling all templates yourself. If your project provided its own templates then this change will not affect anything, but if you rely on (some of) the built-in templates your project may be affected. - The Azure provider has been removed in favor of keeping the Microsoft provider. Both providers were targeting the same goal. Security notice --------------- - Facebook: Using the JS SDK flow, it was possible to post valid access tokens originating from other apps. Facebook user IDs are scoped per app. By default that user ID (not the email address) is used as key while authenticating. Therefore, such access tokens can not be abused by default. However, in case ``SOCIALACCOUNT_EMAIL_AUTHENTICATION`` was explicitly enabled for the Facebook provider, these tokens could be used to login. 0.57.0 (2023-09-24) ******************* Note worthy changes ------------------- - Added Django password validation help text to ``password1`` on set/change/signup forms. - Microsoft: the tenant parameter can now be configured per app. - SAML: Added support for additional configuration parameters, such as contacts, and support for certificate rotation. - The enumeration prevention behavior at signup is now configurable. Whether or not enumeration can be prevented during signup depends on the email verification method. In case of mandatory verification, enumeration can be properly prevented because the case where an email address is already taken is indistinguishable from the case where it is not. However, in case of optional or disabled email verification, enumeration can only be prevented by allowing the signup to go through, resulting in multiple accounts sharing same email address (although only one of the accounts can ever have it verified). When enumeration is set to ``True``, email address uniqueness takes precedence over enumeration prevention, and the issue of multiple accounts having the same email address will be avoided, thus leaking information. Set it to ``"strict"`` to allow for signups to go through. Fixes ===== - Fixed ``?next=`` URL handling in the SAML provider. - During 2FA, pending logins were incorrectly removed when e.g. Django was asked to serve a ``/favicon.ico`` URL. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.4 2023/11/07 22:38:09 wiz Exp $ d3 1 a3 1 DISTNAME= django-allauth-0.58.2 d16 1 a16 1 DEPENDS+= ${PYPKGPREFIX}-django>=3.2:../../www/py-django3 @ 1.4 log @*: latest py-sphinx only support Python 3.9+ @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.3 2023/08/31 17:36:13 adam Exp $ d3 1 a3 1 DISTNAME= django-allauth-0.55.2 d13 2 d25 1 a25 1 .include "../../lang/python/egg.mk" @ 1.3 log @py-django-allauth: updated to 0.55.2 0.55.2 (2023-08-30) ******************* Fixes ----- - Email confirmation: An attribute error could occur when following invalid email confirmation links. 0.55.1 (2023-08-30) ******************* Fixes ----- - SAML: the lookup of the app (``SocialApp``) was working correctly for apps configured via the settings, but failed when the app was configured via the Django admin. - Keycloak: fixed reversal of the callback URL, which was reversed using ``"openid_connect_callback"`` instead of ``"keycloak_callback"``. Although the resulting URL is the same, it results in a ``NoReverseMatch`` error when ``allauth.socialaccount.providers.openid_connect`` is not present in ``INSTALLED_APPS``. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.2 2023/08/30 13:52:00 adam Exp $ d21 1 a21 1 PYTHON_VERSIONS_INCOMPATIBLE= 27 @ 1.2 log @py-django-allauth: updated to 0.55.0 0.55.0 (2023-08-22) ******************* Note worthy changes ------------------- - Introduced a new setting ``ACCOUNT_PASSWORD_RESET_TOKEN_GENERATOR`` that allows you to specify the token generator for password resets. - Dropped support for Django 2.x and 3.0. - Officially support Django 4.2. - New providers: Miro, Questrade - It is now possible to manage OpenID Connect providers via the Django admin. Simply add a `SocialApp` for each OpenID Connect provider. - There is now a new flow for changing the email address. When enabled (``ACCOUNT_CHANGE_EMAIL``), users are limited to having exactly one email address that they can change by adding a temporary second email address that, when verified, replaces the current email address. - Changed spelling from "e-mail" to "email". Both are correct, however, the trend over the years has been towards the simpler and more streamlined form "email". - Added support for SAML 2.0. Thanks to `Dskrpt `_ for sponsoring the development of this feature! - Fixed Twitter OAuth2 authentication by using basic auth and adding scope `tweet.read`. - Added (optional) support for authentication by email for social logins (see ``SOCIALACCOUNT_EMAIL_AUTHENTICATION``). Security notice --------------- - Even with account enumeration prevention in place, it was possible for a user to infer whether or not a given account exists based by trying to add secondary email addresses . This has been fixed -- see the note on backwards incompatible changes. Backwards incompatible changes ------------------------------ - Data model changes: when ``ACCOUNT_UNIQUE_EMAIL=True`` (the default), there was a unique constraint on set on the ``email`` field of the ``EmailAddress`` model. This constraint has been relaxed, now there is a unique constraint on the combination of ``email`` and ``verified=True``. Migrations are in place to automatically transition, but if you have a lot of accounts, you may need to take special care using ``CREATE INDEX CONCURRENTLY``. @ text @d1 1 a1 1 # $NetBSD: Makefile,v 1.1 2023/06/04 02:29:21 markd Exp $ d3 1 a3 1 DISTNAME= django-allauth-0.55.0 @ 1.1 log @py-django-allauth: add version 0.54.0 Integrated set of Django applications addressing authentication, registration, account management as well as 3rd party (social) account authentication. @ text @d1 1 a1 1 # $NetBSD$ d3 1 a3 1 DISTNAME= django-allauth-0.54.0 d13 6 a22 6 DEPENDS+= ${PYPKGPREFIX}-django>=3.2:../../www/py-django3 DEPENDS+= ${PYPKGPREFIX}-openid>=3.0.8:../../security/py-openid DEPENDS+= ${PYPKGPREFIX}-requests-[0-9]*:../../devel/py-requests DEPENDS+= ${PYPKGPREFIX}-requests-oauthlib>=0.3.0:../../security/py-requests-oauthlib DEPENDS+= ${PYPKGPREFIX}-JWT>=1.7:../../textproc/py-JWT @