Fix missing username in uWSGI logs when using API Token authenticatio…

[tejas0077]

Description

When using API Token authentication, uWSGI logs show a dash (-) instead
of the username, making it impossible to trace which user made which API
request. This breaks audit trails and forensic analysis.

Web interface requests correctly log the username, but API token requests do not.

Fix: Added ApiTokenUsernameLoggingMiddleware that sets REMOTE_USER in the
request metadata after authentication is complete, so uWSGI can log the
correct username regardless of the authentication method used.

Fixes #13751

Test results

Manually traced the middleware execution. The middleware runs after
AuthenticationMiddleware so the user is always authenticated before
we attempt to set REMOTE_USER.

Documentation

No documentation changes needed.

[dryrunsecurity]

🔴 Risk threshold exceeded.

This pull request modifies sensitive files (dojo/middleware.py and dojo/remote_user.py); the scanner flagged these as sensitive edits and notes that sensitive paths and allowed authors can be configured in .dryrunsecurity.yaml. Review these changes carefully since they touch configured codepaths marked as sensitive.

🔴 Configured Codepaths Edit in dojo/middleware.py (drs_946a7bec)

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

🔴 Configured Codepaths Edit in dojo/middleware.py (drs_54209686)

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

🔴 Configured Codepaths Edit in dojo/remote_user.py (drs_56c8b7df)

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.

---

Comment to provide feedback on these findings.

Report false positive: @dryrunsecurity fp [FINDING ID] [FEEDBACK]
Report low-impact: @dryrunsecurity nit [FINDING ID] [FEEDBACK]

Example: @dryrunsecurity fp drs_90eda195 This code is not user-facing

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

[Maffooch]

This is partially implemented here: https://github.com/DefectDojo/django-DefectDojo/blob/c89ac6087b553301e95214eb59d31a657641b8f6/dojo/remote_user.py

Please update this middleware instead of adding a new one

[tejas0077]

Thanks @Maffooch! I'll update the existing dojo/remote_user.py middleware instead of adding a new one. Will push the changes shortly.

[tejas0077]

Thanks @Maffooch! I've moved the logic into the existing RemoteUserMiddleware in remote_user.py using process_response, and removed the separate ApiTokenUsernameLoggingMiddleware from middleware.py and settings.dist.py. Please take a look!

[valentijnscholten]

This is partially implemented here: https://github.com/DefectDojo/django-DefectDojo/blob/c89ac6087b553301e95214eb59d31a657641b8f6/dojo/remote_user.py

Please update this middleware instead of adding a new one

@Maffooch I don't see how REMOTE_USER authentication is related to apikey authentication?

[tejas0077]

Hi @valentijnscholten, you raise a valid point. RemoteUserMiddleware only runs when AUTH_REMOTEUSER_ENABLED=True, so placing the logic there won't fix the issue for API token authentication.

Looking at the codebase again, I see there's already an existing middleware in dojo/middleware.py that sets dd_user via uwsgi.set_logvar(). Would it make more sense to extend that existing middleware to also set REMOTE_USER for all authenticated requests, regardless of the auth method used?

@Maffooch could you clarify where the right place would be to handle this for API token auth specifically?