Open 0x4d4e opened 2 years ago
This comment was wrong ;) - not the root cause.
I was able to reproduce this locally using the latest 'dev' branch. Same steps as above:
Interestingly, sending another request via the API succeeded, even though no login/access via the Web UI was performed. Only the first API request after a restart reliably failed. I guess this is caused by some caching. When running the 'debug' environment/configuration to attach a remote debugger, no self-healing was observed and all repeated API requests failed.
I think this issue is caused by the behavior described in this comment: https://github.com/encode/django-rest-framework/issues/760#issuecomment-391127616
Since the result of the TokenAuthentication is not yet available when the Middlewares are executed, request.user is None or AnonymousUser during these steps. For example, the call to https://github.com/DefectDojo/django-DefectDojo/blob/c101e47b294863877cd68a82d0cc60f8017b45b1/dojo/user/queries.py#L56 as seen in the stack trace above is affected and also the call to crum.get_current_user() does not result in the correct user being set (https://github.com/DefectDojo/django-DefectDojo/blob/c101e47b294863877cd68a82d0cc60f8017b45b1/dojo/user/queries.py#L58).
A quick and very hackish poc for a fix is implemented in PR https://github.com/DefectDojo/django-DefectDojo/pull/6478
I think the alternative to fixing request.user via the middleware would be to move the authorization logic to a later step (after TokenAuthentication from restframework was executed). I did not attempt this approach since I did not want to touch the existing authorization logic.
Bug description
We are running DefectDojo on ECS Fargate using a template that is based on the included docker-compose file. After resuming the service after it was paused due to inactivity on our test environments or after redeploying the service (e.g. due to a new version) accessing DefectDojo via the API/access key fails with the exception included below.
The exception message points at an issue with the request caching?
API access works again after a user authenticates via the web interface.
Steps to reproduce
Expected behavior Accessing the API via the API key should immediately work after resuming/redeploying the containers.
Deployment method (select with an
X
)Environment information
Logs The following logs are output by the uwsgi container when attempting to access the instance via the API after a restart/redeployment.