LG-11873: doc auth w/ selfie in non-prod hosted envs#9729
Conversation
a1a3d0c to
42070a7
Compare
679a4f6 to
90f4ae9
Compare
There was a problem hiding this comment.
This does not consider config following?
return false if Identity::Hostdata.env == 'prod'
return false unless IdentityConfig.store.doc_auth_selfie_capture_enabledThere was a problem hiding this comment.
Oh, i see, it's in the form. But should we make decision in one place?
There was a problem hiding this comment.
fair point @dawei-nava 🤔 ...
consolidated ✅ 😄
There was a problem hiding this comment.
If we put all the checks in decorated_sp_session.selfie_required?, then we don't have to duplicate this method here.
There was a problem hiding this comment.
I think the controller already checks the hostdata env stuff in the concern? Or we wanna double check.
There was a problem hiding this comment.
yes, it does ... but added check on the way out to FE be extra careful
There was a problem hiding this comment.
I feel like the double-checking of both hostdata and config implies a distrust in our configuration, where we should be confident in using it? Assuming the default is false in production.
| return false if Identity::Hostdata.env == 'prod' | |
| return false unless IdentityConfig.store.doc_auth_selfie_capture_enabled | |
| decorated_sp_session.selfie_required? | |
| IdentityConfig.store.doc_auth_selfie_capture_enabled && decorated_sp_session.selfie_required? |
There was a problem hiding this comment.
@aduth - I understand that the FF is there and reliable. However, given the sensitivity of selfie not yet ready for our higher envs, we want it to be impossible for this to go live in production as this is an explicit requirement. No matter what config changes are made, this hardcoding guards any mistakes from a config standpoint.
There was a problem hiding this comment.
decorated_sp_session.selfie_required? will also return false if IdentityConfig.store.doc_auth_selfie_capture_enabled is not set to true. I understand about wanting to make triple-sure this doesn't go live accidentally, and at the same time code encapsulation is also useful. Maybe we could put any extra checks in selfie_required and just use that everywhere instead of having an extra method liveness_checking_enabled?. Happy to rename the method if that would help.
There was a problem hiding this comment.
I agree with Amir. Since this is such a sensitive feature, I think it's good to have an extra safeguard in place.
soniaconnolly
left a comment
There was a problem hiding this comment.
Great spec coverage! Overall looks good, some comments on repeated code. Commenting now, will approve later after running through the test plan.
There was a problem hiding this comment.
decorated_sp_session.selfie_required? will also return false if IdentityConfig.store.doc_auth_selfie_capture_enabled is not set to true. I understand about wanting to make triple-sure this doesn't go live accidentally, and at the same time code encapsulation is also useful. Maybe we could put any extra checks in selfie_required and just use that everywhere instead of having an extra method liveness_checking_enabled?. Happy to rename the method if that would help.
There was a problem hiding this comment.
If we put all the checks in decorated_sp_session.selfie_required?, then we don't have to duplicate this method here.
There was a problem hiding this comment.
Does this method add value?
There was a problem hiding this comment.
@soniaconnolly - 👍🏿 ... it allows us to access liveness_checking_required for selfie validator
There was a problem hiding this comment.
I think it also works if you use the attr_reader method of :liveness_checking_required in the validator.
There was a problem hiding this comment.
i tried again to remove it and it worked 👍🏿
There was a problem hiding this comment.
Same question as above: does this method add value? And if they both add value, let's call them the same thing.
There was a problem hiding this comment.
@soniaconnolly - i see what you mean ... upon your suggestion, i attempted changing it but soon realized that it will be too similar naming (liveness_checking_required vs liveness_checking_required?) to the existing attribute name and open the opportunity to a bad typo mistake where we evaluate whether or not to put a selfie in the payload
There was a problem hiding this comment.
Do we need to repeat this method definition in the spec?
There was a problem hiding this comment.
@soniaconnolly - reusing the approach that was present but introducing the guards which we also want to test ... it allows us to reduce a lot of lines of coding in this test .... do you have any simple suggestions on how to improve this?
There was a problem hiding this comment.
Paired on this and we ended up renaming the method to include_liveness_expected to make it clear that it's not overriding the method definition in code.
There was a problem hiding this comment.
Should we check the costs function actually adds the cost?
There was a problem hiding this comment.
you're right @dawei-nava ... we shouldn't forget about this ... i think that's out of scope for this ticket ... created LG-11965 so we won't lose track of this ... 👍🏿
There was a problem hiding this comment.
Ran through the test plan, LGTM!
Additionally tested logging in at Identity Verified level with a Biometric Comparison verified account, and that worked too.
Couple additional notes from testing, not in scope for this PR:
- In development, I'm still seeing the "don't have a license" questionnaire at the end of Document Capture. As far as I know I don't have any relevant config flags set in my local application.yml. Maybe application.yml.default has it on in development? (Yep, that was it, putting in a PR to turn that off.)
- Should we add something to VerifyInfo that indicates a selfie was captured?
9d50c1e to
a8c1a33
Compare
There was a problem hiding this comment.
This method looks very similar to liveness_checking_enabled? in DocumentCaptureConcern. Why not include the DocumentCaptureConcern at the top of the file and then call liveness_checking_enabled? here?
Putting all the checks in decorated_sp_session.selfie_required? would work, too. That also wouldn't require including DocumentCaptureConcern in this file. 🤔
There was a problem hiding this comment.
I think it also works if you use the attr_reader method of :liveness_checking_required in the validator.
There was a problem hiding this comment.
I think this should say 'does not request FE to display selfie'
There was a problem hiding this comment.
I know this predates this PR, but since you are working in this spec, do you mind combining the before statements on lines 32-40 into one before statement?
There was a problem hiding this comment.
Nit: Should the context block also say required? Do we want to be consistent in which term we use?
There was a problem hiding this comment.
Thanks for including this spec! 🙏🏻
There was a problem hiding this comment.
🤔 I wonder if it's worth updating this shared example in order to pass liveness_checking_required to it as an argument? Thinking out loud here.
Co-authored-by: Sonia Connolly <sonia.connolly@gsa.gov>
002a432 to
63c35f8
Compare
🎫 Ticket
LG-11873
🛠 Summary of changes
📜 Testing Plan
Provide a checklist of steps to confirm the changes.
Enable selfie feature flag
Disable selfie feature flag
Enable selfie feature flag