Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication credentials for v3 API running locally in Docker #2112

Open
chartjes opened this issue Feb 18, 2020 · 3 comments
Open

Authentication credentials for v3 API running locally in Docker #2112

chartjes opened this issue Feb 18, 2020 · 3 comments

Comments

@chartjes
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

mythmon commented Feb 19, 2020

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 [email protected] where [email protected] 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
Copy link
Contributor

mythmon commented Mar 24, 2020

  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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants