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

Add /users endpoint #5506

Merged
merged 1 commit into from
Sep 23, 2020
Merged

Add /users endpoint #5506

merged 1 commit into from
Sep 23, 2020

Conversation

eloquence
Copy link
Member

@eloquence eloquence commented Sep 17, 2020

Resolves #5490

Description

Adds the /users endpoint as described in the issue and subsequent comments, enumerating non-sensitive information for all users.

Documentation PR dependent on this one:
freedomofpress/securedrop-docs#3

Status

Ready for review.

Test plan

Spin up a development environment from this PR.

  • Observe that you see this endpoint listed on http://localhost:8081/api/v1
  • Observe that you cannot access this endpoint at http://localhost:8081/api/v1/users without an authentication token
  • Observe that you can access the list of users when providing a valid authentication token as part of the request (see example below)
  • Observe that the list of users only includes the expected fields (UUID, username, first name, last name)

Token usage example (curl)

$ curl -X POST -H "Content-Type: application/json" \ 
  -d '{"username":"journalist", "passphrase":"correct horse battery staple profanity oil chewy", "one_time_code": "123456"}' \ 
  'http://localhost:8081/api/v1/token'

$ curl -H "Authorization: Token TOKEN_HERE" http://localhost:8081/api/v1/users

Checklist

  • Linting (make lint) and tests (make test) pass in the development container (tested for API tests)

fields are excluded."""

try:
last_login = self.last_access.isoformat() + 'Z'
Copy link
Member Author

@eloquence eloquence Sep 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I first attempted to request a to_json representation of all users in the dev env, this raised an exception due to the last_access attribute never having been set. While not required for the bare representation, it seemed sensible to add a check here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nit/feel free to ignore] you could set last_login within the bare clause where bare is false since that's the only place it's used

[suggestion] instead of "bare" you could call it "all_details" or "all_info"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it makes sense to also add an "all_details" check that defaults to false for the "/user" endpoint. otherwise, we'll have some admins with is_admin set and some admins without is_admin set depending on who has logged into the workstation. looking at the table directly as an admin could be misleading. also, we don't do anything with this information in the client and should probably wait to include it once we finish our client admin stories.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you could set last_login within the bare clause where bare is false since that's the only place it's used

That makes sense; we'll still have to do the try check to avoid errors on newly created users, but I'll move it.

instead of "bare" you could call it "all_details" or "all_info"

I like all_info, will use that. I was trying to avoid suggesting that it's a full representation, since both representations exclude credentials.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also add an "all_details" check that defaults to false for the "/user" endpoint

Could you clarify? This PR doesn't modify the behavior of the /user endpoint (it currently already includes the is_admin Boolean), do you think that it should?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made the other two changes in aa0a591

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you clarify? This PR doesn't modify the behavior of the /user endpoint (it currently already includes the is_admin Boolean), do you think that it should?

Oh, I see, I forgot that we don't store the is_admin result from the /user endpoint so we don't have to worry about the situation I brought up where some admin acounts will have is_admin set and some will not. Okay, ignore previous comment.

@eloquence eloquence marked this pull request as ready for review September 18, 2020 01:03
{
"first_name": "Nellie",
"last_name": "Bly",
"username": "nbly",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<3

{
"first_name": "Daniel",
"last_name": "Ellsberg",
"username": "dellsberg",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a-ha! now i get the whole "dellsberg" reference in the test data

fields are excluded."""

try:
last_login = self.last_access.isoformat() + 'Z'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nit/feel free to ignore] you could set last_login within the bare clause where bare is false since that's the only place it's used

[suggestion] instead of "bare" you could call it "all_details" or "all_info"

fields are excluded."""

try:
last_login = self.last_access.isoformat() + 'Z'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it makes sense to also add an "all_details" check that defaults to false for the "/user" endpoint. otherwise, we'll have some admins with is_admin set and some admins without is_admin set depending on who has logged into the workstation. looking at the table directly as an admin could be misleading. also, we don't do anything with this information in the client and should probably wait to include it once we finish our client admin stories.

sssoleileraaa
sssoleileraaa previously approved these changes Sep 21, 2020
Copy link
Contributor

@sssoleileraaa sssoleileraaa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alright this looks good to me. I think it would be good followup to add the all_info check to the "/user" endpoint eventually for consistency. plus it's easy to get confused about how we're adding is_admin to the response body yet never using or storing it.

looks like lint is failing, so once that's fixed I'll approve

@conorsch conorsch dismissed sssoleileraaa’s stale review September 21, 2020 22:49

Dismissing review at @creviera's request, needs a rebase and likely another round of linting

Resolves #5490

Includes the following tests:
- Test that endpoint exists
- Test that endpoint requires authorization
- Test that endpoint enumerates all users
- Test that endpoint returns only expected fields
Copy link
Contributor

@sssoleileraaa sssoleileraaa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

  • Observe that you see this endpoint listed on http://localhost:8081/api/v1
  • Observe that you cannot access this endpoint at http://localhost:8081/api/v1/users without an authentication token
  • Observe that you can access the list of users when providing a valid authentication token as part of the request (see example below)
  • Observe that the list of users only includes the expected fields (UUID, username, first name, last name)

Copy link
Contributor

@conorsch conorsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! @creviera already reviewed, but I'll add further confirmation:

  • Observe that you see this endpoint listed on http://localhost:8081/api/v1
  • Observe that you cannot access this endpoint at http://localhost:8081/api/v1/users without an authentication token
  • Observe that you can access the list of users when providing a valid authentication token as part of the request
  • Observe that the list of users only includes the expected fields (UUID, username, first name, last name) - The the first/last fields were present, although empty, which I'd expect given the create-dev-data logic.

Not blocking, but let's look for an opportunity to test the "last_login" field later on.

@conorsch
Copy link
Contributor

Proceeding with merge. There's a bit more review required for #5505. Once both #5505 & #5506 are in, we'll rebase and review #5513.

@conorsch conorsch merged commit 56200ba into develop Sep 23, 2020
@emkll emkll mentioned this pull request Sep 28, 2020
22 tasks
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

Successfully merging this pull request may close these issues.

Add /users endpoint to API
3 participants