Authentication credentials for v3 API running locally in Docker

[chartjes]

I am writing the rest of the v3 API contract tests using a version of Normandy running locally and require authentication credentials to do so. A brief conversation in Slack with @jaredlockhart indicates there might be some setting that needs to be changed to make this happen.

Here is a sample call built using http://localhost:8000/api/v3/swagger/

curl -X POST "http://localhost:8000/api/v3/approval_request/1/approve/" -H "accept: application/json" -H "authorization: Basic YWRkOnBhc3N3ZA==" -H "Content-Type: application/json" -H "X-CSRFToken: 7pLjg7I3wpD0RPlt1FjSVQkzCbUfZ7KnuLTZDg7Icb4rJKctjIAdNuylwEmDARXj" -d "{ "approved": true, "approver": { "first_name": "string", "last_name": "string", "email": "string" }, "comment": "string", "creator": { "first_name": "string", "last_name": "string", "email": "string" }}"

and it currently returns:

{"detail":"Authentication credentials were not provided."}

[chartjes]

It was suggested that I create a superuser in the Docker container and use the user and password as authentication credentials. Based on the response header that is generated I believe what I need is a bearer token of some kind:

access-control-allow-origin: *
allow: POST, OPTIONS
connection: close
content-length: 58
content-security-policy: form-action 'self'; base-uri 'none'; worker-src 'none'; default-src 'self'; block-all-mixed-content; object-src 'none'; frame-src 'none'; report-uri
content-type: application/json
date: Wed, 19 Feb 2020 15:32:09 GMT
server: gunicorn/19.9.0
vary: Accept, Origin
www-authenticate: Bearer <===================
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block

[mythmon]

The docker-compose setup uses the Development configuration by default. That configuration includes an authentication called "InsecureEmailAuthentication". I'm not sure why that wasn't included in the www-authenticate header.

To use InsecureEmailAuthentication (code with docstring here), pass a header of Authorization: Insecure user@example.com where user@example.com should be replaced with the email address of your super user.

I'd like to keep this issue open to deal with

1. Why didn't www-authenticate show this?
2. We should update the docs to make this clearer.

[mythmon]

1. Why didn't www-authenticate show this?

Although the spec allows the WWW-Authenticate header to contain multiple challenges, our API layer, DRF, has specifically chosen to only include the first. Our development environment supports both Bearer and Insecure authentication methods, and Bearer comes first.

We have a few options:

1. We could leave it as is, and rely on our docs to save us.
2. We could switch the order of the authentication methods, so that Insecure comes first. That would have helped @chartjes, but isn't really better in my opinion.
3. We could subclass DRF's APIView to have the behavior we want, and integrate that subclass into all of our views, which would be kind of a pain.

I don't like any of these options, but I'm leaning towards 1. @jaredlockhart do you have thoughts?