Fix the TOTP reset link to properly redirect back to itself upon logging in

[ccostino]

In order to provide a better customer experience when resetting TOTP, we need to update the TOTP reset page to properly redirect a user if they are not already logged in and are prompted to login first.

A customer sent a support request wondering why they were being redirected to the login dashboard instead of the TOTP reset link; the login page doesn't properly take you back to the TOTP reset in this case, nor is there an option to get to it from the login or accounts dashboards. Perhaps we should add links to it on one of those pages as well.

Acceptance Criteria

• GIVEN a customer tries to reset TOTP by going directly to the TOTP reset page
  AND is not already logged in
  WHEN the customer logs in successfully
  THEN they are redirected to the reset TOTP page directly.
• GIVEN a customer would like to reset their TOTP
  AND is already logged in
  WHEN the customer goes to the login or accounts dashboard
  THEN they are given an additional option/link to go to the TOTP reset page

---

Security considerations

None - this is public information and customer-facing functionality

Implementation sketch

• Fix the login redirect when being prompted to login after going to TOTP reset page
• Add an option/link to the TOTP reset page to the login and/or accounts dashboard

[ccostino]

Apparently this can still be an issue even for someone who is already logged in. When they try and go to reset their TOTP even after being logged in, they're just redirected to the login dashboard.

[ccostino]

@bengerman13, do you have any insights into what might be going on with this? I remember you mentioning something about the workflow that wasn't quite right.

One working theory I also had about this is a similar situation as what happens with SecureAuth. Sometimes the cookies become stale so to speak, and while you're still prompted for a login the old session information sticks around and you get kicked to that authorization page but not actually logged in. You have to clear your history or at least any SecureAuth items before you can try again.

[bengerman13]

I don't recall exactly, but some of the big hurdles were:

• something about registering the redirect endpoints with UAA - currently, I think we have just one redirect endpoint, and there was something that stops us from registering more
• there's a really weird artifact in uaa-extras where every request gets sent through the first-login endpoint, and that's confusing and complicated for reasons I don't exactly recall

Adding to all of that is that there is almost no testing on this app, and even less documentation on how it should work.

I think before we take on any tasks on this app, we need to, at minimum:

• create a fully functional local dev setup
• document all of the features of the app
• write unit and happy-path integration tests for all the features of the apps
• set up happy-path acceptance tests for all of the features of the app <- this is hard because of email

[bengerman13]

(this ticket should also probably be moved to the cg-uaa-extras repo)