FAQ | This is a LIVE service | Changelog

Skip to content
Snippets Groups Projects
  1. Mar 16, 2025
  2. Feb 19, 2025
  3. Oct 02, 2024
  4. Mar 05, 2024
  5. Mar 04, 2024
  6. Feb 07, 2024
  7. Feb 06, 2024
  8. Jan 30, 2024
  9. Oct 17, 2023
    • Dr Rich Wareham's avatar
      f39fa10c
    • Dr Rich Wareham's avatar
    • Dr Rich Wareham's avatar
      feat: verify API Gateway id token in request · e7255d7c
      Dr Rich Wareham authored
      Add verification for the Authorization header for incoming requests. The
      defaults are to verify that the request is appropriately authenticated
      with a Google service account corresponding to the API Gateway.
      
      Expected issuer, authorised parties, issuer certificate URLs, etc can be
      customised via settings. This is unlikely to be used in production but
      is useful when combined with the API Gateway emulator for local
      development.
      
      Verification can be disabled entirely by setting an appropriately
      dire-named setting.
      
      Tests have been updated to exercise verification assuming that the
      Google verification library works as documented.
      
      Closes #4
      e7255d7c
  10. Oct 02, 2023
  11. Sep 21, 2023
  12. Jun 29, 2023
    • Dr Rich Wareham's avatar
      c5e5ce1a
    • Dr Rich Wareham's avatar
      feat: add user when authenticating · 9c53abab
      Dr Rich Wareham authored
      When authenticating a principal add a synthetic "APIGatewayUser" object
      as the request user. This object is not backed by a database object but
      does have an id meaning that DRF templates used to render the API views
      will correctly identify the authenticated user.
      
      This unpacked somewhat because of a slight break with Django convention
      exhibited by this app.
      
      One needs to be _very_ careful with what is imported as a side-effect of
      importing the top-level application module. That is because that module
      is imported at application configure time as part of configuring the
      application. It follows that applications in general are not yet
      configured when the top-level application module is imported.
      
      The top-level module here then directly imports some of the
      implementation. So now our implementation must not rely on applications
      having been configured at import time.
      
      We got away with this due to the simplicity of the application but
      attempting to derive from AnonymousUser triggered the problem: trying to
      import anything from django.contrib.auth.models threw an exception about
      applications not being configured.
      
      The convention for DRF authentication classes is for them to sit in a
      submodule named "authentication" within the top-level application. This
      is for good reason; trying to have them in the top-level leads to this
      sort of pain.
      
      Unfortunately we have users in the wild using
      "apigatewayauth.APIGatewayAuthentication" in their settings and so we
      need to support that until users are fixed up to use
      "apigatewayauth.authentication.APIGatewayAuthentication".
      
      In the meantime, do some nasty hackery to support what was required by
      the original issue.
      
      Closes #2
      9c53abab
    • Dr Rich Wareham's avatar
      Merge branch 'support-later-djangos' into 'main' · 97b8a448
      Dr Rich Wareham authored
      Support later Django versions
      
      Closes #1
      
      See merge request !3
      0.0.3
      97b8a448
    • Dr Rich Wareham's avatar
      chore:setup.py: bump version number · d548a18b
      Dr Rich Wareham authored
      Update (or, more correctly, create) the changelog in the process.
      d548a18b
    • Dr Rich Wareham's avatar
      feat: move to using common Python CI templates · e7a88daf
      Dr Rich Wareham authored
      We now have common Python project CI templates which, while continuing
      to support PyPI publication, also allow for parallel matrix testing with
      tox.
      
      The GitLab CI configuration in this repo dates from a time before this
      feature was in GitLab (as noted in the comments) and so had to work
      around it by creating a lot of templated jobs.
      
      Simplify the CI configuration by making use of the common template.
      e7a88daf
    • Dr Rich Wareham's avatar
      feat: support later Djangos · fe9ff8b2
      Dr Rich Wareham authored
      fe9ff8b2
  13. Mar 25, 2022
  14. Mar 23, 2022
  15. Mar 18, 2022
Loading