User login

[mbodeantor]

Adding password reset endpoint, splitting out queries into functions for unit tests, splitting out API key generation to its own endpoint

To test login:

1. signing up and / or logging in via the /login route
   To test: navigate to /login and perform whichever operation. (Sign up a user, or you can use [email protected] | Password1! to log in)

2. Gating protected routes.
   To test: If not logged in, navigate to /change-password (a blank page presently), and you should be redirected to /login. Log in, and you should be redirected back to /change-password.

3. Automatically refresh user's access tokens if they are active within 1 minute of current token expiration.
   To test: Log in with a user. Wait 4 minutes. Click, press keys, or scroll anywhere in the UI (doesn't have to be a button or anything). Wait another minute and navigate to /change-password. You should not be redirected back to /login.

4. Automatically log a user out on user action when the access token has expired
   To test: Log in with a user and navigate to /change-password. Wait 5+ minutes and click/press/scroll anywhere in the UI. You should be redirected to /login (if not on a protected route, there will be no navigation, so it won't interrupt users who are using /, /search, etc.

To test changing password:

1. Go to /login and log in with any user.
2. Navigate to /change-password
3. Change your password—you will be automatically logged back in with the new password.

To test reseting password

1. Sign up a user with a valid email address (you can use Ethereal to create a testing account)
2. Log out
3. From /login, click Click here to reset it
4. Enter the email you used to sign up.
5. Follow the link that is delivered in the email.
6. Change password
7. After success, click Click here to log in
8. Confirm that the updated password logs your user in.

[josh-chamberlain]

@mbodeantor nice! I think this needs a docs update and ideally steps to test before I would be able to review it, from a technical skills perspective

[kalenluciano]

This looks good to me!

[mbodeantor]

@josh-chamberlain Docs are updated here: https://app.gitbook.com/o/-MXypK5ySzExtEzQU6se/s/-MXyolqTg_voOhFyAcr-/~/changes/464/api/endpoints/admin

Here are the new tests I added for the new endpoints to try them out:

data-sources-app/regular_api_checks.py

Line 156 in e4c5577

def test_put_user():

def test_put_user():
    response = requests.get(
        "https://data-sources.pdap.io/api/user",
        headers=HEADERS,
        json={"email": "test2", "password": "test"},
    )

    return response.json()["data"] == "Successfully updated password"


# api-key
def test_get_api_key():
    response = requests.get(
        "https://data-sources.pdap.io/api/api_key",
        headers=HEADERS,
        json={"email": "test2", "password": "test"},
    )

    return len(response.json()["api_key"]) > 0

[mbodeantor]

Put this on hold so the front end work can be added here

[joshuagraber]

I've started looking into the client work for this @mbodeantor and just have a question for you on the password reset endpoint.

[joshuagraber]

@mbodeantor Needed to make a few updates to design-system to properly accomplish the client work for this. Symlinked locally and added a screen recording, but if you want to test more thoroughly, I can push some testing code to this branch.

[joshuagraber]

One other thing I'm wondering here @josh-chamberlain @mbodeantor (a next-week question 😅 ): how are we handling sessions? Are we handling this entirely client-side? Or do we want to use a time-bound access-token solution returned from the backend?

FWIW, I vote for the latter, as it's much more secure (particularly since we'll eventually be adding the ability for users to modify records in the db).

[josh-chamberlain]

@joshuagraber @mbodeantor I advocate for the latter, too—it's what we've talked about, and supported by auth libraries if needed

[joshuagraber]

and supported by auth libraries if needed

@josh-chamberlain I think it makes sense to use a trusted lib rather than building ourselves, but I defer to @mbodeantor on that.

I pushed the initial /login client work. It's testable. I confirmed by signing up with a new user and logging in with that user.
I'll pause the client work for now, though, because depending on how we implement the token stuff, it may change that approach and the approach for the password reset stuff.

[joshuagraber]

Hey @mbodeantor I'm working on writing some tests for the change/reset password routes, and in the process I noticed that login is failing. Behavior is the same from browser or curling from command line. (post to /user is okay, so is post to /reset-password. Can't test put to /user without logging in a user, but I assume that's okay as well).

Request:

{
  "email": "[email protected]",
  "password": "Password1!"
}

Response (500):

{
    "message": "Expected a string value"
}

[mbodeantor]

@joshuagraber can you verify SECRET_KEY is in your environment locally? I had this issue in GH tests but they're passing locally for me

[joshuagraber]

can you verify SECRET_KEY is in your environment locally?

@mbodeantor Yes it is. Did that value change recently?

[mbodeantor]

No, but it wasn't being used recently.

[joshuagraber]

No, but it wasn't being used recently

So does this need to be passed to the API somewhere? It's exported via the shell alias, but the client app doesn't access it in code right now.

I had this issue in GH tests but they're passing locally for me

Are you able to run the client app locally and log in via the browser with your current configuration?

[josh-chamberlain]

definitely good enough to merge into dev!