Merge pull request #179 from sirosen/release/0.19.0

Release v0.19.0

.github/CODEOWNERS

@@ -1,2 +1,2 @@
 # The automate team will be requested for review on all opened PRs.
-* @ada-globus @derek-globus @jakeglobus @kurtmckee @sirosen
+* @ada-globus @derek-globus @jakeglobus @kurtmckee @MaxTueckeGlobus @sirosen

.github/workflows/ci.yaml

@@ -15,11 +15,11 @@ jobs:
     runs-on: "ubuntu-latest"
     steps:
       - name: "Checkout the repo"
-        uses: "actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29" # v4.1.6
+        uses: "actions/checkout@d632683dd7b4114ad314bca15554477dd762a938" # v4.2.0
 
       - name: "Setup Python"
         id: "setup-python"
-        uses: "actions/setup-python@82c7e631bb3cdc910f68e0081d67478d79c6982d" # v5.1.0
+        uses: "actions/setup-python@f677139bbe7f9c59b41e40162b753c062f5d49a3" # v5.2.0
         with:
           python-version: "3.12"
 
@@ -58,7 +58,7 @@ jobs:
       wheel-filename: "${{ steps.build-wheel.outputs.wheel-filename }}"
     steps:
       - name: "Checkout the repo"
-        uses: "actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29" # v4.1.6
+        uses: "actions/checkout@d632683dd7b4114ad314bca15554477dd762a938" # v4.2.0
 
       - name: "Identify the week number"
         run: |
@@ -67,7 +67,7 @@ jobs:
 
       - name: "Setup Python"
         id: "setup-python"
-        uses: "actions/setup-python@82c7e631bb3cdc910f68e0081d67478d79c6982d" # v5.1.0
+        uses: "actions/setup-python@f677139bbe7f9c59b41e40162b753c062f5d49a3" # v5.2.0
         with:
           python-version: "3.11"
           cache: "pip"
@@ -84,7 +84,7 @@ jobs:
           echo "wheel-filename=$(find globus_action_provider_tools-*.whl | head -n 1)" >> "$GITHUB_OUTPUT"
 
       - name: "Upload the artifact"
-        uses: "actions/upload-artifact@65462800fd760344b1a7b4382951275a0abb4808" # v4.3.3
+        uses: "actions/upload-artifact@50769540e7f4bd5e21e526ee35c689e35e0d6874" # v4.4.0
         with:
           name: "globus_action_provider_tools-${{ github.sha }}.whl"
           path: "${{ steps.build-wheel.outputs.wheel-filename }}"
@@ -138,7 +138,7 @@ jobs:
 
     steps:
       - name: "Checkout the repo"
-        uses: "actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29" # v4.1.6
+        uses: "actions/checkout@d632683dd7b4114ad314bca15554477dd762a938" # v4.2.0
 
       - name: "Identify the week number"
         shell: "bash"
@@ -148,7 +148,7 @@ jobs:
 
       - name: "Setup Python"
         id: "setup-python"
-        uses: "actions/setup-python@82c7e631bb3cdc910f68e0081d67478d79c6982d" # v5.1.0
+        uses: "actions/setup-python@f677139bbe7f9c59b41e40162b753c062f5d49a3" # v5.2.0
         with:
           python-version: "${{ matrix.python-version }}"
           cache: "pip"
@@ -185,7 +185,7 @@ jobs:
           ${{ env.venv-path }}/pip install tox
 
       - name: "Download the artifact"
-        uses: "actions/download-artifact@65a9edc5881444af0b9093a5e628f2fe47ea3b2e" # v4.1.7
+        uses: "actions/download-artifact@fa0a91b85d4f404e444e00e005971372dc801d16" # v4.1.8
         with:
           name: "globus_action_provider_tools-${{ github.sha }}.whl"
 

.github/workflows/release.yml

@@ -11,12 +11,12 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout source code
-        uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4.1.6
+        uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4.2.0
         with:
           fetch-depth: 1
 
       - name: Set target python version
-        uses: actions/setup-python@82c7e631bb3cdc910f68e0081d67478d79c6982d # v5.1.0
+        uses: actions/setup-python@f677139bbe7f9c59b41e40162b753c062f5d49a3 # v5.2.0
         with:
           python-version: "3.11"
 

.pre-commit-config.yaml

@@ -11,28 +11,28 @@ repos:
       - id: check-useless-excludes
 
   - repo: https://github.com/pre-commit/pre-commit-hooks
-    rev: v4.6.0
+    rev: v5.0.0
     hooks:
       - id: trailing-whitespace
       - id: end-of-file-fixer
       - id: check-yaml
       - id: check-json
       - id: check-added-large-files
 
-  - repo: https://github.com/sirosen/alphabetize-codeowners
-    rev: 0.0.1
+  - repo: https://github.com/sirosen/texthooks
+    rev: 0.6.7
     hooks:
       - id: alphabetize-codeowners
 
   # Enforce Python 3.8+ idioms.
   - repo: https://github.com/asottile/pyupgrade
-    rev: v3.16.0
+    rev: v3.17.0
     hooks:
       - id: pyupgrade
         args: [--py38-plus]
 
   - repo: https://github.com/psf/black-pre-commit-mirror
-    rev: 24.4.2
+    rev: 24.10.0
     hooks:
       - id: black
 
@@ -42,19 +42,19 @@ repos:
       - id: isort
 
   - repo: https://github.com/pycqa/flake8
-    rev: 7.0.0
+    rev: 7.1.1
     hooks:
       - id: flake8
         additional_dependencies:
-          - flake8-bugbear==24.4.26
+          - flake8-bugbear==24.8.19
 
   - repo: https://github.com/sirosen/slyp
-    rev: 0.6.1
+    rev: 0.7.1
     hooks:
       - id: slyp
 
   - repo: https://github.com/rhysd/actionlint
-    rev: v1.7.1
+    rev: v1.7.3
     hooks:
       - id: actionlint
 

CHANGELOG.rst

@@ -10,6 +10,69 @@ Unreleased changes are documented in files in the `changelog.d`_ directory.
 
 ..  scriv-insert-here
 
+.. _changelog-0.19.0:
+
+0.19.0 — 2024-10-18
+===================
+
+Features
+--------
+
+- The token introspect checking and caching performed in ``AuthState`` has
+  been improved.
+
+  - The cache is keyed off of token hashes, rather than raw token strings.
+
+  - The ``exp`` and ``nbf`` values are no longer verified, removing the
+    possibility of incorrect treatment of valid tokens as invalid due to clock
+    drift.
+
+  - Introspect response caching caches the raw response even for invalid
+    tokens, meaning that Action Providers will no longer repeatedly introspect
+    a token once it is known to be invalid.
+
+  - Scope validation raises a new, dedicated error class,
+    ``globus_action_provider_tools.authentication.InvalidTokenScopesError``, on
+    failure.
+
+Changes
+-------
+
+- The ``TokenChecker`` class has been removed and replaced in all cases with an
+  ``AuthStateBuilder`` which better matches the purpose of this class.
+
+- The ``check_token`` flask-specific helper has been replaced with a
+  ``FlaskAuthStateBuilder`` which subclasses ``AuthStateBuilder`` and
+  specializes it to handle a ``flask.Request`` object.
+
+- The ``aud`` field of token introspect responses is no longer validated and
+  fields associated with it have been removed. This includes changes to
+  function and class initializer signatures.
+
+  - The ``expected_audience`` field is no longer supported in ``AuthState`` and
+    ``TokenChecker``. It has been removed from the initializers for these
+    classes.
+
+  - ``globus_auth_client_name`` has been removed from ``ActionProviderBlueprint``.
+
+  - ``client_name`` has been removed from ``add_action_routes_to_blueprint``.
+
+Development
+-----------
+
+- Move to `src/` tree layout
+
+- Refactor ``AuthState.get_authorizer_for_scope`` without changing its
+  primary outward semantics. The ``bypass_dependent_token_cache`` argument
+  has been removed from its interface, as it is not necessary to expose
+  with the improved implementation.
+
+Removed
+-------
+
+- ``globus_action_provider_tools.testing`` has been removed. Users who were
+  relying on these components should make use of their own fixtures and mocks.
+
 .. _changelog-0.18.0:
 
 0.18.0 — 2024-06-14

RELEASING.md

@@ -0,0 +1,42 @@
+# Releasing
+
+- Determine a new version number, `VERSION=...`
+
+- Make sure your repo is on `main` and up to date;
+    `git checkout main; git pull`
+
+- Checkout a release branch, `git checkout -b release/$VERSION`
+
+- Update the version number with `poetry version $VERSION`
+
+- Update the changelog, `scriv collect --edit`
+
+- Add, commit, and push the release branch
+
+```
+git add pyproject.toml CHANGELOG.rst changelog.d/
+git commit -m "Bump version for release v$VERSION"
+git push -u origin release/$VERSION
+```
+_Note: this assumes `origin` is your desired upstream._
+
+- Create a PR against the `production` branch;
+    `gh pr create -B production -t "Release v$VERSION"`
+
+- After any changes and approval, merge the PR, checkout `production`, and pull;
+    `git checkout production; git pull`
+
+- Create a release tag and push;
+    `git tag -s "v$(poetry version -s)" -m "v$(poetry version -s)"`
+    `git push --tags`
+
+- Create a GitHub release, which will auto-publish to pypi
+    `gh release create "v$(poetry version -s)" --title "v$(poetry version -s)"`
+
+- Merge `production` back to `main` by opening and merging a PR:
+
+    ```
+    gh pr create -B main -H production -t "Merge back production->main ($(date +"%Y-%m-%d"))" -b '' -l no-news-is-good-news
+    ```
+
+- Delete the release branch; `git branch -d release/$VERSION`

WORKFLOW.md

@@ -13,10 +13,7 @@ Some commands may not be available until the virtual environment is created and
 * [Version numbering](#version-numbering)
 * [Priority git branches](#priority-git-branches)
 * [Everyday development](#everyday-development)
-* [Preparing a feature release](#preparing-a-feature-release)
 * [Preparing a hotfix release](#preparing-a-hotfix-release)
-* [Merging release branches](#merging-release-branches)
-* [Publishing the new version](#publishing-the-new-version)
 
 
 ## Version numbering
@@ -76,28 +73,6 @@ git checkout -b "$BRANCH_NAME"
 Feature branches are merged back to `main`, and only to `main`.
 
 
-## Preparing a feature release
-
-When the code or documentation is ready for release, a new feature release will be created.
-Feature releases begin by creating a new branch off of `main`
-(or, alternatively, by branching off an agreed-upon merge commit in `main`).
-
-```shell
-read -p "Enter the feature release version: " NEW_VERSION
-BRANCH_NAME="release/$NEW_VERSION"
-
-# If deploying from main:
-git checkout main
-git pull origin
-git checkout -b "$BRANCH_NAME"
-
-# Alternatively, if deploying from an agreed-upon merge commit:
-git checkout -b "$BRANCH_NAME" <SHA>
-```
-
-Next, proceed to the [Merging release branches](#merging-release-branches) section.
-
-
 ## Preparing a hotfix release
 
 If a bug is found in production and must be fixed immediately, this requires a hotfix release.
@@ -118,74 +93,3 @@ After creating the hotfix branch, fix that bug, create a changelog fragment
 and commit the changes in the hotfix branch!
 
 Next, proceed to the [Merging release branches](#merging-release-branches) section.
-
-
-## Merging release branches
-
-**NOTE**:
-The steps in this document must be performed in a release or hotfix branch.
-See the
-[Preparing a feature release](#preparing-a-feature-release)
-or
-[Preparing a hotfix release](#preparing-a-hotfix-release)
-section for steps to create a release or hotfix branch.
-
-After creating a release or hotfix branch,
-you must follow these steps to merge the branch to `production` and `main`:
-
-1. On the branch that is to be released, prepare the code and documentation for release.
-   1. Bump the version.
-        - If the release is a hotfix, use ``poetry version patch``
-        - If the release is a backwards-compatible change use ``poetry version patch``
-        - If the release is non-backwards compatible, use ``poetry version minor``
-   2. Bump copyright years as appropriate.
-   3. Collect changelog fragments as appropriate.
-   4. Run unit/integration/CI/doc tests as appropriate.
-   5. Commit all changes to git.
-
-2. Push the branch to GitHub.
-
-3. Create a new pull request to merge to `production`.
-   1. Select `production` as the "base" merge branch.
-   2. Select the release or hotfix branch as the "compare" merge branch.
-   3. Wait for CI test results (and approvals, when possible).
-
-      It is the release engineer's discretion to ask for and require PR approvals.
-      A release branch will usually contain code that has already been reviewed, unless it is a hotfix.
-      If the release is a hotfix, it is recommended to get approvals.
-
-      > WARNING: **Merge conflicts**
-      >
-      > Merge conflicts halt the release process when merging to `production`
-      > unless it is a trivial conflict (like the "version" in `pyproject.toml`).
-
-   4. Merge the branch to `production`. Do not delete the branch!
-
-4. Create a new tag and a new release.
-
-   1. Click on the "Releases" section. Then click "Draft a new release".
-   2. Click the "Choose a tag" dropdown, type the new version, and press Enter.
-   3. Select `production` as the target branch.
-   4. Type the new version as the release title.
-   5. Paste the changelog as the release description.
-   6. Click "Publish release" to publish the new tag and release on GitHub.
-
-5. Create a new pull request to merge to `main`.
-
-   1. Select `main` as the "base" merge branch.
-   2. Select the release or hotfix branch as the "compare" merge branch.
-   3. Wait for CI test results (and approvals, if needed).
-
-      > NOTE: **Merge conflicts**
-      >
-      > A merge conflict at this stage does NOT halt the release process.
-      > However, approval is required after resolving the conflict.
-
-   4. Merge the branch to `main`.
-
-6. Delete the release branch.
-
-
-## Publishing the new version
-
-Code updates are automatically published to PyPI when a new release is created on GitHub.

docs/source/toolkit.rst

@@ -26,10 +26,6 @@ common requirements so the focus can be on the logic of the Action provided.
 5. :doc:`Caching guide <toolkit/caching>` for tweaking the performance of Action
 Providers with relation to Globus Auth.
 
-6. :doc:`Testing tools <toolkit/testing>` provides various resources for
-stubbing Authentication out of an Action Provider and providing a simple way of
-validating an Action Provider's behavior.
-
 .. toctree::
    :maxdepth: 1
    :hidden:
@@ -39,7 +35,6 @@ validating an Action Provider's behavior.
    toolkit/data_types
    toolkit/flask_helpers
    toolkit/validation
-   toolkit/testing
 
 
 .. _Pydantic: https://pydantic-docs.helpmanual.io/