Merge tag '1.7.0' into pr-1.7.1-grn

Author: ryanluker

.github/workflows/test.yml

@@ -37,7 +37,7 @@ jobs:
     - name: Install Python dependencies
       run: |
         python -m pip install --upgrade pip
-        python -m pip install --upgrade tox tox-gh-actions django
+        python -m pip install --upgrade tox tox-gh-actions
 
     - name: Tox tests
       run: |

.pre-commit-config.yaml

@@ -5,7 +5,7 @@ repos:
       - id: black
         exclude: ^(oauth2_provider/migrations/|tests/migrations/)
   - repo: https://github.com/pre-commit/pre-commit-hooks
-    rev: v4.0.1
+    rev: v4.1.0
     hooks:
       - id: check-ast
       - id: trailing-whitespace

.readthedocs.yml

@@ -1,15 +1,29 @@
-# .readthedocs.yml
+# .readthedocs.yaml
 # Read the Docs configuration file
 # See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
 
 # Required
 version: 2
 
+# Set the version of Python and other tools you might need
+build:
+  os: ubuntu-20.04
+  tools:
+    python: "3.9"
+    # You can also specify other tool versions:
+    # nodejs: "16"
+    # rust: "1.55"
+    # golang: "1.17"
+
 # Build documentation in the docs/ directory with Sphinx
 sphinx:
-  configuration: docs/conf.py
+   configuration: docs/conf.py
+
+# If using Sphinx, optionally build your docs in additional formats such as PDF
+# formats:
+#    - pdf
 
+# Optionally declare the Python requirements required to build your docs
 python:
-  version: 3.7
-  install:
-    - requirements: docs/requirements.txt
+   install:
+   - requirements: docs/requirements.txt

AUTHORS

@@ -1,11 +1,11 @@
 Authors
-=======
+-------
 
 Massimiliano Pippi
 Federico Frenguelli
 
 Contributors
-============
+------------
 
 Abhishek Patel
 Alan Crosswell
@@ -24,6 +24,7 @@ Bas van Oostveen
 Dave Burkholder
 David Fischer
 David Smith
+Dawid Wolski
 Diego Garcia
 Dulmandakh Sukhbaatar
 Dylan Giesler
@@ -46,6 +47,7 @@ Michael Howitz
 Paul Dekkers
 Paul Oswald
 Pavel Tvrdík
+Patrick Palacin
 Peter Carnesciali
 Petr Dlouhý
 Rodney Richardson
@@ -62,6 +64,7 @@ Jadiel Teófilo
 pySilver
 Łukasz Skarżyński
 Shaheed Haque
-Andrea Greco
 Vinay Karanam
-
+Eduardo Oliveira
+Andrea Greco
+Dominik George

CHANGELOG.md

@@ -14,7 +14,47 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ### Security
   -->
 
-## [Unreleased]
+## [1.7.0] 2022-01-23
+
+### Added
+* #969 Add batching of expired token deletions in `cleartokens` management command and `models.clear_expired()`
+  to improve performance for removal of large numers of expired tokens. Configure with
+  [`CLEAR_EXPIRED_TOKENS_BATCH_SIZE`](https://django-oauth-toolkit.readthedocs.io/en/latest/settings.html#clear-expired-tokens-batch-size) and
+  [`CLEAR_EXPIRED_TOKENS_BATCH_INTERVAL`](https://django-oauth-toolkit.readthedocs.io/en/latest/settings.html#clear-expired-tokens-batch-interval).
+* #1070 Add a Celery task for clearing expired tokens, e.g. to be scheduled as a [periodic task](https://docs.celeryproject.org/en/stable/userguide/periodic-tasks.html).
+* #1062 Add Brazilian Portuguese (pt-BR) translations.
+* #1069 OIDC: Add an alternate form of
+  [get_additional_claims()](https://django-oauth-toolkit.readthedocs.io/en/latest/oidc.html#adding-claims-to-the-id-token)
+  which makes the list of additional `claims_supported` available at the OIDC auto-discovery endpoint (`.well-known/openid-configuration`).
+
+### Fixed
+* #1012 Return 200 status code with `{"active": false}` when introspecting a nonexistent token
+  per [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662#section-2.2). It had been incorrectly returning 401.
+
+## [1.6.3] 2022-01-11
+
+### Fixed
+* #1085 Fix for #1083 admin UI search for idtoken results in `django.core.exceptions.FieldError: Cannot resolve keyword 'token' into field.`
+
+### Added
+* #1085 Add admin UI search fields for additional models.
+
+## [1.6.2] 2022-01-06
+
+**NOTE: This release reverts an inadvertently-added breaking change.**
+
+### Fixed
+
+* #1056 Add missing migration triggered by [Django 4.0 changes to the migrations autodetector](https://docs.djangoproject.com/en/4.0/releases/4.0/#migrations-autodetector-changes).
+* #1068 Revert #967 which incorrectly changed an API. See #1066.
+
+## [1.6.1] 2021-12-23
+
+### Changed
+* Note: Only Django 4.0.1+ is supported due to a regression in Django 4.0.0. [Explanation](https://github.com/jazzband/django-oauth-toolkit/pull/1046#issuecomment-998015272)
+
+### Fixed
+* Miscellaneous 1.6.0 packaging issues.
 
 ## [1.6.0] 2021-12-19
 ### Added
@@ -32,7 +72,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 * #991 Update documentation of [REFRESH_TOKEN_EXPIRE_SECONDS](https://django-oauth-toolkit.readthedocs.io/en/latest/settings.html#refresh-token-expire-seconds) to indicate it may be `int` or `datetime.timedelta`.
 * #977 Update [Tutorial](https://django-oauth-toolkit.readthedocs.io/en/stable/tutorial/tutorial_01.html#) to show required `include`.
 
-## Removed
+### Removed
 * #968 Remove support for Django 3.0 & 3.1 and Python 3.6
 * #1035 Removes default_app_config for Django Deprecation Warning
 * #1023 six should be dropped

README.rst

@@ -35,6 +35,10 @@ capabilities to your Django projects. Django OAuth Toolkit makes extensive use o
 `OAuthLib <https://github.com/idan/oauthlib>`_, so that everything is
 `rfc-compliant <http://tools.ietf.org/html/rfc6749>`_.
 
+Note: If you have issues installing Django 4.0.0, it is because we only support
+Django 4.0.1+ due to a regression in Django 4.0.0. Besides 4.0.0, Django 2.2+ is supported.
+`Explanation <https://github.com/jazzband/django-oauth-toolkit/pull/1046#issuecomment-998015272>`_.
+
 Contributing
 ------------
 

docs/contributing.rst

@@ -96,6 +96,24 @@ When deploying your app, don't forget to compile the messages with::
     django-admin compilemessages
 
 
+Migrations
+==========
+
+If you alter any models, a new migration will need to be generated. This step is frequently missed
+by new contributors. You can check if a new migration is needed with::
+
+    tox -e migrations
+
+And, if a new migration is needed, use::
+
+    django-admin makemigrations --settings tests.mig_settings
+
+Auto migrations frequently have ugly names like `0004_auto_20200902_2022`. You can make your migration
+name "better" by adding the `-n name` option::
+
+    django-admin makemigrations --settings tests.mig_settings -n widget
+
+
 Pull requests
 =============
 
@@ -154,7 +172,8 @@ When you begin your PR, you'll be asked to provide the following:
 If your PR is not yet ready to be merged mark it as a Work-in-Progress
 By prepending `WIP:` to the PR title so that it doesn't get inadvertently approved and merged.
 
-The repo managers will be notified of your pull request and it will be reviewed, in the meantime you can continue to add
+Make sure to request a review by assigning Reviewer `jazzband/django-oauth-toolkit`.
+This will assign the review to the project team and a member will review it. In the meantime you can continue to add
 commits to your topic branch (and push them up to GitHub) either if you see something that needs changing, or in
 response to a reviewer's comments.  If a reviewer asks for changes, you do not need to close the pull and reissue it
 after making changes. Just make the changes locally, push them to GitHub, then add a comment to the discussion section
@@ -255,7 +274,7 @@ The following notes are to remind the project maintainers and leads of the steps
 review and merge PRs and to publish a new release.
 
 Reviewing and Merging PRs
-------------------------
+-------------------------
 
 - Make sure the PR description includes the `pull request template
   <https://github.com/jazzband/django-oauth-toolkit/blob/master/.github/pull_request_template.md>`_
@@ -271,18 +290,25 @@ PRs that are incorrectly merged may (reluctantly) be reverted by the Project Lea
 Publishing a Release
 --------------------
 
-Only Project Leads can publish a release to pypi.org and rtfd.io. This checklist is a reminder
-of steps.
+Only Project Leads can `publish a release <https://jazzband.co/about/releases>`_ to pypi.org
+and rtfd.io. This checklist is a reminder of the required steps.
 
 - When planning a new release, create a `milestone
   <https://github.com/jazzband/django-oauth-toolkit/milestones>`_
   and assign issues, PRs, etc. to that milestone.
 - Review all commits since the last release and confirm that they are properly
-  documented in the CHANGELOG. (Unfortunately, this has not always been the case
-  so you may be stuck documenting things that should have been documented as part of their PRs.)
+  documented in the CHANGELOG. Reword entries as appropriate with links to docs
+  to make them meaningful to users.
 - Make a final PR for the release that updates:
 
   - CHANGELOG to show the release date.
-  - setup.cfg to set `version = ...`
-
-- Once the final PR is committed push the new release to pypi and rtfd.io.
+  - `oauth2_provider/__init__.py` to set `__version__ = "..."`
+
+- Once the final PR is merged, create and push a tag for the release. You'll shortly
+  get a notification from Jazzband of the availability of two pypi packages (source tgz
+  and wheel). Download these locally before releasing them.
+- Do a `tox -e build` and extract the downloaded and bullt wheel zip and tgz files into
+  temp directories and do a `diff -r` to make sure they have the same content.
+  (Unfortunately the checksums do not match due to timestamps in the metadata
+  so you need to compare all the files.)
+- Once happy that the above comparison checks out, approve the releases to Pypi.org.

docs/management_commands.rst

@@ -16,5 +16,13 @@ If ``cleartokens`` runs daily the maximum delay before a refresh token is
 removed is ``REFRESH_TOKEN_EXPIRE_SECONDS`` + 1 day. This is normally not a
 problem since refresh tokens are long lived.
 
+To prevent the CPU and RAM high peaks during deletion process use ``CLEAR_EXPIRED_TOKENS_BATCH_SIZE`` and
+``CLEAR_EXPIRED_TOKENS_BATCH_INTERVAL`` settings to adjust the process speed.
+
 Note: Refresh tokens need to expire before AccessTokens can be removed from the
 database. Using ``cleartokens`` without ``REFRESH_TOKEN_EXPIRE_SECONDS`` has limited effect.
+
+The ``cleartokens`` action can also be scheduled as a `Celery periodic task`_
+by using the ``clear_tokens`` task (automatically registered when using Celery).
+
+.. _Celery periodic task: https://docs.celeryproject.org/en/stable/userguide/periodic-tasks.html

docs/oidc.rst

@@ -245,17 +245,45 @@ required claims, eg ``iss``, ``aud``, ``exp``, ``iat``, ``auth_time`` etc),
 and the ``sub`` claim will use the primary key of the user as the value.
 You'll probably want to customize this and add additional claims or change
 what is sent for the ``sub`` claim. To do so, you will need to add a method to
-our custom validator.
-Standard claim ``sub`` is included by default, for remove it override ``get_claim_list``::
+our custom validator. It takes one of two forms:
+
+The first form gets passed a request object, and should return a dictionary
+mapping a claim name to claim data::
+    class CustomOAuth2Validator(OAuth2Validator):
+        def get_additional_claims(self, request):
+            claims = {}
+            claims["email"] = request.user.get_user_email()
+            claims["username"] = request.user.get_full_name()
+
+            return claims
+
+The second form gets no request object, and should return a dictionary
+mapping a claim name to a callable, accepting a request and producing
+the claim data::
     class CustomOAuth2Validator(OAuth2Validator):
         def get_additional_claims(self):
             def get_user_email(request):
-                return request.user.get_full_name()
+                return request.user.get_user_email()
+
+            claims = {}
+            claims["email"] = get_user_email
+            claims["username"] = lambda r: r.user.get_full_name()
+
+            return claims
+
+Standard claim ``sub`` is included by default, to remove it override ``get_claim_dict``.
+
+In some cases, it might be desirable to not list all claims in discovery info. To customize
+which claims are advertised, you can override the ``get_discovery_claims`` method to return
+a list of claim names to advertise. If your ``get_additional_claims`` uses the first form
+and you still want to advertise claims, you can also override ``get_discovery_claims``.
 
-            # Element name, callback to obtain data
-            claims_list = [ ("email", get_sub_cod),
-                        ("username", get_user_email) ]
-            return claims_list
+In order to help lcients discover claims early, they can be advertised in the discovery
+info, under the ``claims_supported`` key. In order for the discovery info view to automatically
+add all claims your validator returns, you need to use the second form (producing callables),
+because the discovery info views are requested with an unauthenticated request, so directly
+producing claim data would fail. If you use the first form, producing claim data directly,
+your claims will not be added to discovery info.
 
 .. note::
     This ``request`` object is not a ``django.http.Request`` object, but an

docs/requirements.txt

@@ -1,5 +1,5 @@
-Django>=3.0,<3.1
+Django
 oauthlib>=3.1.0
 m2r>=0.2.1
 mistune<2
-.
+-e .