Hotfix: SET Handler using subject_type instead of new-value

[elipe17]

Summary of Changes

• Update identifier changed logic to NOT mutate the User model. The SET does NOT send the UUID of the user for this event and can optionally include the new email that the old email was changed to. Because of this, we can NOT deterministically try to update user data from this event. We track that the event occurred and that is it. When the user re-authenticates for the following session after the event, we are then able to deterministically update the username and email on the User model.

How to Test

• Deploy to an environment tied to Login.gov push_url config. E.g. raft, staging, prod
• Authenticate with login.gov and elect to view your login.gov profile
• Add a new email address to your account and verify it. Ensure this email is NOT already associated with a user in TDP
• Delete your old email account
• Verify you see an Email Changed event in the SET tab in the DAC
• Logout of your current session
• Log back in with the email you just changed to
• Verify your new email is set on your Django user
• You can also verify on the SETs that the user reference is now your new email as opposed to it saying you changed your old email to old email

See screenshot below for my test verification in raft.

Deliverables

More details on how deliverables herein are assessed included here.

Deliverable 1: Accepted Features

Checklist of ACs:

• [insert ACs here]
• lfrohlich and/or adpennington confirmed that ACs are met.

Deliverable 2: Tested Code

• Are all areas of code introduced in this PR meaningfully tested?
  • If this PR introduces backend code changes, are they meaningfully tested?
  • If this PR introduces frontend code changes, are they meaningfully tested?
• Are code coverage minimums met?
  • Frontend coverage: [insert coverage %] (see CodeCov Report comment in PR)
  • Backend coverage: [insert coverage %] (see CodeCov Report comment in PR)

Deliverable 3: Properly Styled Code

• Are backend code style checks passing on CircleCI?
• Are frontend code style checks passing on CircleCI?
• Are code maintainability principles being followed?

Deliverable 4: Accessible

• Does this PR complete the epic?
• Are links included to any other gov-approved PRs associated with epic?
• Does PR include documentation for Raft's a11y review?
• Did automated and manual testing with iamjolly and ttran-hub using Accessibility Insights reveal any errors introduced in this PR?

Deliverable 5: Deployed

• Was the code successfully deployed via automated CircleCI process to development on Cloud.gov?

Deliverable 6: Documented

• Does this PR provide background for why coding decisions were made?
• If this PR introduces backend code, is that code easy to understand and sufficiently documented, both inline and overall?
• If this PR introduces frontend code, is that code easy to understand and sufficiently documented, both inline and overall?
• If this PR introduces dependencies, are their licenses documented?
• Can reviewer explain and take ownership of these elements presented in this code review?

Deliverable 7: Secure

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any new security issues?
• If new issues detected, is investigation and/or remediation plan documented?

Deliverable 8: User Research

Research product(s) clearly articulate(s):

• the purpose of the research
• methods used to conduct the research
• who participated in the research
• what was tested and how
• impact of research on TDP
• (if applicable) final design mockups produced for TDP development

[codecov]

Codecov Report

❌ Patch coverage is 93.84615% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.99%. Comparing base (1eefc88) to head (b529a9e).

Files with missing lines	Patch %	Lines
tdrs-backend/tdpservice/security/event_handler.py	76.47%	4 Missing ⚠️

Additional details and impacted files

@@                 Coverage Diff                 @@
##           release/v4.18.0    #5824      +/-   ##
===================================================
+ Coverage            93.98%   93.99%   +0.01%     
===================================================
  Files                  534      534              
  Lines                24115    24173      +58     
  Branches               620      620              
===================================================
+ Hits                 22664    22721      +57     
- Misses                1338     1339       +1     
  Partials               113      113              

Flag	Coverage Δ
dev-backend	94.28% <93.84%> (+0.01%)	⬆️
dev-frontend	91.84% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...end/tdpservice/security/test/test_event_handler.py	95.65% <100.00%> (+0.33%)	⬆️
...ers/test/test_primary_login_gov_security_events.py	100.00% <100.00%> (ø)
tdrs-backend/tdpservice/security/event_handler.py	93.51% <76.47%> (-0.24%)	⬇️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1eefc88...b529a9e. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[elipe17]

@jtimpe @raftmsohani & @mattcoleanderson could you guys test this out again now that the deployment blocker has been lifted? You will need to deploy this branch again I believe.

[elipe17]

Please hold on this

[ADPennington]

@elipe17 testing notes below. tested a few times but do not see my second email address (ap34) anywhere in the system.

Deploy to an environment tied to Login.gov push_url config. E.g. raft, staging, prod

qasp

Authenticate with login.gov and elect to view your login.gov profile

signed in as gsa.alex user

Add a new email address to your account and verify it

added ap34 user

Delete your old email account

deleted gsa.alex user

Verify your new email is set on your Django user

signed in as ap34 user but only gsa.alex user is recognized. no evidence of ap34 user in backend.

[elipe17]

@elipe17 testing notes below. tested a few times but do not see my second email address (ap34) anywhere in the system.

Deploy to an environment tied to Login.gov push_url config. E.g. raft, staging, prod

qasp

Authenticate with login.gov and elect to view your login.gov profile

signed in as gsa.alex user

Add a new email address to your account and verify it

added ap34 user

Delete your old email account

deleted gsa.alex user

Verify your new email is set on your Django user

signed in as ap34 user but only gsa.alex user is recognized. no evidence of ap34 user in backend.

@ADPennington this can only be tested in the environments I listed. Login.gov does not allow us to supply multiple SET push urls unfortunately.

[elipe17]

@raftmsohani @mattcoleanderson @jtimpe @ADPennington I made some fixes and realized I still had a misunderstanding with the shape of the SET; Specifically the identifier changed SET. I updated the code and tested with user accounts that didn't already exist in the DB. This is deployed to Raft, so please give it a try yourself.

[ADPennington]

@elipe17 testing notes below. Please confirm that the final result is expected.

Deploy to an environment tied to Login.gov push_url config. E.g. raft, staging, prod

raft

Authenticate with login.gov and elect to view your login.gov profile

signed in as ap34 user

Add a new email address to your account and verify it

added gsa.alex user

Delete your old email account

deleted ap34 user

Verify your new email is set on your Django user

signed in as ap34 user and it didnt work. tried as gsa.alex user and it was recognized. no evidence of ap34 user in backend. i assume this is expected since these accounts are associated with the same login.gov uuid?

[elipe17]

@elipe17 testing notes below. Please confirm that the final result is expected.

Deploy to an environment tied to Login.gov push_url config. E.g. raft, staging, prod

raft

Authenticate with login.gov and elect to view your login.gov profile

signed in as ap34 user

Add a new email address to your account and verify it

added gsa.alex user

Delete your old email account

deleted ap34 user

Verify your new email is set on your Django user

signed in as ap34 user and it didnt work. tried as gsa.alex user and it was recognized. no evidence of ap34 user in backend. i assume this is expected since these accounts are associated with the same login.gov uuid?

Correct, all the references to ap34 would transition to gsa.alex. There is no way for us to preserve the old email references since they are tied to the same login.gov uuid.

[elipe17]

@ADPennington are we good to merge this?

[ADPennington]

@ADPennington are we good to merge this?

I think so. Could you briefly explain the last change since testing? @elipe17 I think it was based on Mo's feedback

[elipe17]

@ADPennington are we good to merge this?

I think so. Could you briefly explain the last change since testing? @elipe17 I think it was based on Mo's feedback

Absolutely! All we did was move the user email updating logic so that it happens after a user is confirmed to be active if the user is not active we don't want to update their email until they can actually use the application.

[ADPennington]

🚀🚀