CH-242 add user cache

[filippomc]

Closes CH-242

Implemented solution

Added cache in the middleware right after keycloak token check

How to test this PR

...

Sanity checks:

• The pull request is explicitly linked to the relevant issue(s)
• The issue is well described: clearly states the problem and the general proposed solution(s)
• In this PR it is explicitly stated how to test the current change
• The labels in the issue set the scope and the type of issue (bug, feature, etc.)
• The relevant components are indicated in the issue (if any)
• All the automated test checks are passing
• All the linked issues are included in one Sprint
• All the linked issues are in the Review state
• All the linked issues are assigned

Breaking changes (select one):

• The present changes do not change the preexisting api in any way
• This PR and the issue are tagged as a breaking-change and the migration procedure is well described above

Possible deployment updates issues (select one):

• There is no reason why deployments based on CloudHarness may break after the current update
• This PR and the issue are tagged as alert:deployment

Test coverage (select one):

• Tests for the relevant cases are included in this pr
• The changes included in this pr are out of the current test coverage scope

Documentation (select one):

• The documentation has been updated to match the current changes
• The changes included in this PR are out of the current documentation scope

Nice to have (if relevant):

• Screenshots of the changes
• Explanatory video/animated gif

[Copilot]

Pull request overview

This PR implements user caching in the BearerTokenMiddleware to improve performance by avoiding repeated database queries for Keycloak-authenticated users. The cache stores Django User objects keyed by Keycloak user ID with a configurable TTL (default 60 seconds).

Changes:

• Added Django cache imports and configuration for user caching
• Implemented cache lookup early in the middleware flow to return cached users immediately
• Added cache population at the end of successful authentication flows

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The cached_user retrieved from cache bypasses all the safety checks that ensure a user has a valid Member relationship. The _get_user function and subsequent code have extensive safety guarantees to never assign a user without a Member, but cached users skip these verifications. This could lead to AttributeError exceptions when code tries to access user.member. Consider adding a safety check to verify the cached user still has a valid Member relationship before using it, similar to the checks at lines 146-156.

Suggested change

	request.user = cached_user
	request._cached_user = cached_user
	return self.get_response(request)
	# SAFETY CHECK: Ensure cached user still has a valid Member with matching kc_id
	try:
	member = cached_user.member
	except Member.DoesNotExist:
	log.error(
	"Cached user %s has no Member; ignoring cache and falling back to _get_user.",
	getattr(cached_user, "id", None),
	)
	else:
	if member and getattr(member, "kc_id", None) == kc_user_id:
	request.user = cached_user
	request._cached_user = cached_user
	return self.get_response(request)

[zsinnema]

lgtm