fix username logging in uwsgi for requests with TokenAuthentication

[fopina]

Description

dd_user is the variable we can use in uWSGI logging to log the username on each request, defaulting to - when not authenticated.

However, dd_user is currently not set for DRF / TokenAuthentication requests because DRF only runs after all the middlewares and LoginRequiredMiddleware is the one injecting dd_user

This PR fixes that by setting dd_user after response, when DRF was already executed and user is defined.

Test results

dd_user is already part of DD_UWSGI_LOGFORMAT_DEFAULT

Visit http://localhost:8081/api/v2/users in the browser, username is logged (admin in test)

uwsgi-1             | [pid: 25|app: -|req: -/-] 172.18.0.1 (admin) {52 vars in 1265 bytes} [Sat Feb 14 08:58:34 2026] GET /api/v2/users/ => generated 358 bytes in 42 msecs (HTTP/1.1 200) 9 headers in 499 bytes (1 switches on core 0)
nginx-1             | 172.18.0.1 - - [14/Feb/2026:08:58:34 +0000] "GET /api/v2/users/ HTTP/1.1" 200 358 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:147.0) Gecko/20100101 Firefox/147.0" "-"

curl http://localhost:8081/api/v2/users -H 'Authorization: Token xxxx' and username is logged as- (not authenticated)

uwsgi-1             | [pid: 25|app: -|req: -/-] 172.18.0.1 (-) {34 vars in 429 bytes} [Sat Feb 14 08:59:46 2026] GET /api/v2/users/ => generated 358 bytes in 35 msecs (HTTP/1.1 200) 9 headers in 499 bytes (1 switches on core 0)
nginx-1             | 172.18.0.1 - - [14/Feb/2026:08:59:46 +0000] "GET /api/v2/users/ HTTP/1.1" 200 358 "-" "curl/8.7.1" "-"

With this PR, both cases log the username (firefox and curl user-agents)

uwsgi-1             | [pid: 25|app: -|req: -/-] 172.18.0.1 (admin) {52 vars in 1265 bytes} [Sat Feb 14 08:58:34 2026] GET /api/v2/users/ => generated 358 bytes in 42 msecs (HTTP/1.1 200) 9 headers in 499 bytes (1 switches on core 0)
nginx-1             | 172.18.0.1 - - [14/Feb/2026:08:58:34 +0000] "GET /api/v2/users/ HTTP/1.1" 200 358 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:147.0) Gecko/20100101 Firefox/147.0" "-"

uwsgi-1             | [pid: 25|app: -|req: -/-] 172.18.0.1 (admin) {34 vars in 429 bytes} [Sat Feb 14 08:59:46 2026] GET /api/v2/users/ => generated 358 bytes in 35 msecs (HTTP/1.1 200) 9 headers in 499 bytes (1 switches on core 0)
nginx-1             | 172.18.0.1 - - [14/Feb/2026:08:59:46 +0000] "GET /api/v2/users/ HTTP/1.1" 200 358 "-" "curl/8.7.1" "-"

Checklist

This checklist is for your information.

• Make sure to rebase your PR against the very latest dev.
• Features/Changes should be submitted against the dev.
• Bugfixes should be submitted against the bugfix branch.
• Give a meaningful name to your PR, as it may end up being used in the release notes.
• Your code is flake8 compliant.
• Your code is python 3.13 compliant.
• If this is a new feature and not a bug fix, you've included the proper documentation in the docs at https://github.com/DefectDojo/django-DefectDojo/tree/dev/docs as part of this PR.
• Model changes must include the necessary migrations in the dojo/db_migrations folder.
• Add applicable tests to the unit tests.
• Add the proper label to categorize your PR.

[valentijnscholten]

I think this will work. Do you have some log captures to "prove" it's working?

[fopina]

Mentioned the test criteria so it could be validated but forgot to include the actual logs, I’ll add them later today 👍

[fopina]

Description updated with sample log lines

Also committed a unit test to cover it

[dryrunsecurity]

🔴 Risk threshold exceeded.

This pull request modifies a sensitive file (dojo/middleware.py), triggering a configured "Configured Codepaths Edit" warning and suggesting review or configuration of sensitive paths and allowed authors in .dryrunsecurity.yaml. No explicit blocking action is set, but the change is flagged as failing the risk threshold and should be reviewed.

🔴 Configured Codepaths Edit in dojo/middleware.py

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

We've notified @mtesauro.

---

All finding details can be found in the DryRun Security Dashboard.

[valentijnscholten]

Amazing, thanks!