add user when authenticating

The actual feature introduced by this MR is described in #2 (closed). It is not critical but in summary:

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.

It doesn't really matter if this feature lands or not but this MR mostly fixes a problem which implementing the feature highlighted.

Our library as is subtly breaks a Django convention about importing applications. The fix breaks documented backwards compatibility and so we need to put a bit of a hack in until we can fix up the users. (Currently just card API?) Once fixed we can remove the hack.

The long story:

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 (closed)

assigned to @rjw57

Pinging @rjg21 again. @rjg21: I don't particularly care about the feature being implemented by this MR, it is at best a nice-to-have, but the problem it flagged up does need addressing. The tl:dr:

• We should move APIGatewayAuthentication to a apigatewayauth.authentication module.
• We should fix up the Card API to reference apigatewayauth.authentication.APIGatewayAuthentication instead of apigatewayauth.APIGatewayAuthentication.

We can live without this feature but I guarantee the same problem will crop up for a more desirable feature in future and we might as well fix it now.

Alternatively we could merge a version of the MR without the hack and simultaneously merge a trivial fixup to the Card API?

Pinging @mk2155 in case he has any time tomorrow to look at this (as I'm away) or it can probably wait until next week.

Unfortunately I did not! Apologies, will look over this properly on Monday.

FWIW, merge conflicts with main fixed.

will look over this properly on Monday

Today is Tuesday... so... One day late?

Apologies for the delay, this dropped off my radar completely, LGTM and tested against Card API behaviour seems as expected.

requested review from @rjg21

changed the description

added 2 commits

• 9c53abab - feat: add user when authenticating
• c5e5ce1a - chore:setup.py: bump version and changelog

Compare with previous version

added 5 commits

• c5e5ce1a...85213b38 - 4 commits from branch main
• 57409a46 - Merge branch 'main' into add-user

Compare with previous version

mentioned in merge request !6 (merged)

mentioned in issue #4 (closed)

approved this merge request

requested review from @mk2155

merged

mentioned in commit 0d2a88ce