Get login (no social provider) working in turnkey

[douglasnaphas]

TODO

• Update Puppeteer.
• Add a Cognito User Pool.
• Create a bucket in the stack to hold the Cognito user pool client secret (the client secret bucket).
• Add the user pool id to stack output.
• Get the user pool id in save-client-secret.sh
• Get the client secret in save-client-secret.sh
• Try using Dynamo with DAX instead, because I'm not sure how to get the S3 content, as opposed to the file, with the S3 SDK, although I do this for the scripts in mljsapi... Deferring, going to try with S3
• Save the client secret to the client secret bucket after deploying the stack.
• Have the backend take in the client secret bucket name as an env var.
• Update itest to have a player click log in.
• Find out how to programmatically get the hosted UI URL. Maybe output it? Try with the AWS CLI. It will need to get fed to the fronted, and to itest.
• Do some assertions about the location, specifically asserting that it's what's expected given the Cognito login URL.
• See the above test fail in CI.
• Add a prettier config to package.json at the madliberation level. Read through the options and figure out which I want. Issue Harmonize prettier settings #277 created for this.
• Get the test working, so that clicking the login button takes you to the right URL.
  • Hard-code the URL.
  • Watch it pass in dev.
  • Merge and watch it fail in higher envs. Does failing in test end the build, or does it still attempt prod? it should not attempt prod if test fails, good time to check this. The build did not proceed after the test env integration test step failed, as desired.
  • Save/retrieve the Cognito domain with SSM param store. Deferring, not sure if this would work given the build steps.
  • Make frontend/ require an env var for the build to happen, via checking in a build script. This might need to be reconsidered, since I'm not sure if REACT_APP_ vars are read at build or run time. Update: they're read at build time, so they go into the bundle. Still not sure if this is the right approach, as opposed to receiving a redirect from a backend endpoint.
  • Make backend app.test.js testing that app returns 301 from /login, using Jest.
  • Make the backend /login test look for different outcomes based on the important env vars.
  • Feed the Cognito-related env vars to backend in the CDK webapp stack.
  • Get the login test passing with a redirect returned from /prod/login, which will be linked from the login button.
    • Dev
    • Test
    • Prod
• Pull the IDP URL from Configs, isolating process.env accesses there.
• Use API calls to create and confirm a user for testing, in the build. Better yet, with the SDK in the itest script.
• Use test user in itest.
• Remove the user after the itests.
• Only check for nickname from the JWTs in getUserInfo.
• Get /get-cookies working.

[douglasnaphas]

Cogito legacy prod URL

https://madliberationfederated.auth.us-east-1.amazoncognito.com/login?response_type=code&client_id=25h54vd0cundt7iaeon1rn8a02&redirect_uri=https://api.passover.lol/get-cookies

Domain name: stackname to lower. Actually this should maybe be something with the User Pool ID, because otherwise the names will conflict between test and prod. This is done as of f9465f436e, using a hash of stackname plus the account number.

Redirect uri as CloudFront member to Cognito via constructor. Done in dev.

Client secret as env var with addEnvironment call after user pool creation in lib/MLStack.ts. Except...you can't get the client secret at CDK compile time. Maybe S3?

Likewise for client id and whatever else backend needs to know about user pool

Client id to front end via param store or front end deploy script can get stack output

Likewise for cognito link, or construct it

[douglasnaphas]

Tentative dev login URL:

https://2e1a8eed76dd22adb05b403958634573.auth.us-west-1.amazoncognito.com/login?response_type=code&client_id=lmres6t4lqjdc1tre55t7qte0&redirect_uri=https://d3t14pxg52jdxt.cloudfront.net/prod/get-cookies

[douglasnaphas]

Hosted UI is available in dev at the URL from my previous comment.

[douglasnaphas]

I'm checking in the backend that specific claims are available, when this isn't necessary.

[douglasnaphas]

Users should be able to sign up with just a Mad Liberation username/password, but they should be prompted for an email on signup.

I need to check and see what user info is available in different scenarios (social login, no email provided, etc), because the frontend needs to say "Logged in as X."

[douglasnaphas]

Here's a good piece of progress. It's redirecting to /, as desired.

[douglasnaphas]

Working in manual testing, failing in CI.

[douglasnaphas]

It's failing in CI because I forgot to supply a now-required nickname for the test user.

[douglasnaphas]

Works in prod, closing.