Endpoint to Verify User Identity [#1062] #1111
Conversation
…y request provided it doesn't need separate manual approval by a system admin. - Add a new PrivacyRequest.identity_verified_at timestamp - Add a new PrivacyRequestStatus - "identity_unverified". - Add methods to cache the verification code in Redis for comparison with a default ttl of 10 minutes
- Update changelog. - Add endpoint to postman
…tyVerificationBodyParams that already exists.
There was a problem hiding this comment.
This is looking good @pattisdr ! No blockers aside from using a diff class than SubjectIdentityVerificationBodyParams for the new endpoint req body.
Other than that, I was having trouble pinging the new endpoint in postman due to this error:
{
"detail": "Method Not Allowed"
}
Maybe I have something misconfigured?
| """ | ||
| Generate one-time identity verification code | ||
| """ | ||
| return str(random.choice(range(100000, 999999))) |
There was a problem hiding this comment.
I know the email mocks use a 4-digit code, but I suppose that's more prone to collision / overlap. We should confirm with design that 6 digits will work in the design, too.
There was a problem hiding this comment.
happy to change if needed, I usually see 6 on other applications
| @@ -104,6 +107,7 @@ class Config: | |||
| class PrivacyRequestStatus(str, EnumType): | |||
| """Enum for privacy request statuses, reflecting where they are in the Privacy Request Lifecycle""" | |||
|
|
|||
| identity_unverified = "identity_unverified" | |||
There was a problem hiding this comment.
I'm trying to think whether identity_unverified will always be set or only be set for requests where identity verification is turned on. This is more of a future convo, since I was doing some thinking here around edge cases- #1009 (comment)
There was a problem hiding this comment.
Yeah, different ways to organize. I was viewing it as a state that was only valid when we had identity verification on.
My work in #1010 (no PR yet) has a workflow that sets initial status as identity_unverified when identify verification is "on", otherwise, it sets the initial status to pending. If the identity is later verified, then I change the status from identity_unverified to pending, and also set a field to identity when it was verified to retain that it happened.
There was a problem hiding this comment.
cool, so depending on confirmation from product on #1009 (comment), your workflow sounds good to me!
| privacy_request_id: str, | ||
| *, | ||
| db: Session = Depends(deps.get_db), | ||
| provided_code: SubjectIdentityVerificationBodyParams, |
There was a problem hiding this comment.
ah, I now realize SubjectIdentityVerificationBodyParams was badly named. That was anticipated to only account for email body params, not a request for subject identity verification. Could we make a new class to account for the request body here?
There was a problem hiding this comment.
sure can, an earlier commit already has it!
40fcf6d
…ctIdentityVerificationBodyParams that already exists." This reverts commit 40fcf6d.
|
Reverted the commit @eastandwestwind, back to you! |
…ation_endpoint # Conflicts: # CHANGELOG.md
|
@eastandwestwind for the "Method Not Allowed" Error, you might just need to restart your webserver. |
* Add an endpoint to verify a user's identity before queuing the privacy request provided it doesn't need separate manual approval by a system admin. - Add a new PrivacyRequest.identity_verified_at timestamp - Add a new PrivacyRequestStatus - "identity_unverified". - Add methods to cache the verification code in Redis for comparison with a default ttl of 10 minutes * - Fix linting/copy-paste errors. - Update changelog. - Add endpoint to postman * Add new keys to response bodies. * Instead of using a new VerificationCode schema, use the SubjectIdentityVerificationBodyParams that already exists. * Revert "Instead of using a new VerificationCode schema, use the SubjectIdentityVerificationBodyParams that already exists." This reverts commit 40fcf6d.
👉 Note: Docs will be added in follow-up #1010
Purpose
Add an endpoint to verify the identification code supplied by the user and then queue the privacy request for execution.
#1010 (not implemented yet) will email the user the generated identification code if identity verification is turned on. The user will take that code and submit it to the endpoint added here.
Changes
Add an endpoint to verify a user's identity before queuing the privacy request provided it doesn't need separate manual approval by a system admin.
PrivacyRequest.identity_verified_at timestampidentity_unverified- if identity verification is on, and we go to create a privacy request it will be given this status first, instead ofpending(to be completed in Backend - generate ID verification code #1010)POST {{host}}/privacy-request/{{privacy_request_id}}/verify
{"code": "123456"}Checklist
CHANGELOG.mdfileCHANGELOG.mdfile is being appended toUnreleasedsection in an appropriate category. Add a new category from the list at the top of the file if the needed one isn't already there.Run Unsafe PR Checkslabel has been applied, and checks have passed, if this PR touches any external servicesTicket
Fixes #1062