Start writing decrypted PII to the session based on profile ID#9515
Conversation
There was a problem hiding this comment.
I am considering wrapping this in a block to only run it if the write flag is enabled.
There was a problem hiding this comment.
Actually that does not work because then the pending profile will never get read 🤔
0fbee76 to
173e687
Compare
There was a problem hiding this comment.
I had a little trouble chasing down where this one was called. It is the method that is invoked after a user enters their personal key and their recovery PII is decrypted. The recovery PII is written to the session. The user is sent to the #new action of VerifyPasswordController and then submits to #update which invokes the #decrypted_pii method a few lines down to read that PII from the session and re-encrypt it.
The controllers involved here all have a before action that checks to make sure the user does in fact have a password reset profile and that is the profile that is being operated on.
There was a problem hiding this comment.
nit - Is there a way to make sure that pattern is carried through to future controllers?
There was a problem hiding this comment.
Is this in regards to the before action? The before action to ensure there is a password reset profile is pretty essential to the recovery of a password reset profile. I would expect anybody operating on this code to ensure some sort of control like that is in place. I am not sure of a good way to enforce that that fits within the scope of this change request. There are lots of other bits of code dependent on the password reset profile spread out across these controllers.
This commit builds on #9509. That commit added the ability to write PII to the session under the profile ID associated with that PII. This commit starts using the functionality added in that PR to start writing both the pending and active profile to the session. Additionally in places where PII is written to the session outside the context of password authentication the corresponding profile ID is passed to the PII cacher. [skip changelog]
173e687 to
fc67398
Compare
jmax-gsa
left a comment
There was a problem hiding this comment.
LGTM with one nit; ignore or take up as you see fit.
There was a problem hiding this comment.
nit - Is there a way to make sure that pattern is carried through to future controllers?
soniaconnolly
left a comment
There was a problem hiding this comment.
LGTM. I'm assuming there are specs that test cache_profiles with 0, 1, and 2 active/pending profiles. I looked around a little bit and didn't immediately find them.
I believe this may be what you are looking for: |
This commit builds on #9509. That commit added the ability to write PII to the session under the profile ID associated with that PII.
This commit starts using the functionality added in that PR to start writing both the pending and active profile to the session. Additionally in places where PII is written to the session outside the context of password authentication the corresponding profile ID is passed to the PII cacher.