Conversation
…ubmitted event to Socure flow
| render json: DocAuth::Mock::Socure.instance.selected_fixture_body | ||
| end | ||
|
|
||
| def image_request_endpoint |
There was a problem hiding this comment.
the mock socure endpoints are not currently in use, but i wanted to keep my work in lockstep with it, in case it was revived.
app/jobs/socure_docv_results_job.rb
Outdated
| failures = failures[:socure].presence || failures || {} | ||
| end | ||
|
|
||
| failures.merge(image_errors).presence || nil |
There was a problem hiding this comment.
hm that || nil is not necessary
| sign_in_recaptcha_annotation_enabled: true | ||
| skip_encryption_allowed_list: '[]' | ||
| socure_docv_document_request_endpoint: 'https://sandbox.socure.test/documnt-request' | ||
| socure_docv_images_request_endpoint: 'https://upload.socure.us/api/5.0/documents/' |
There was a problem hiding this comment.
is there a sandbox option? how would i figure that out, it wasn't in the documentation
| parsedAddress: { | ||
| physicalAddress: '123 Example Street', | ||
| physicalAddress2: 'New York City NY 10001', | ||
| physicalAddress2: 'Apt 4', |
There was a problem hiding this comment.
based on the documentation, i think this was an incorrect representation of what is in physicalAddress2, but i could have interpreted the docs incorrectly.
| temp_dir = Dir.mktmpdir(reference_id) | ||
|
|
||
| if passport | ||
| # i don't think this is possible with socure? |
There was a problem hiding this comment.
i was told that passports are on our roadmap with socure, so i am going to leave this in (although we should ask the socure folks what the passport image files are named so we can have an accurate representation here
| { | ||
| 'documentfrontDoc_Back_1_blob.jpg' => :back, | ||
| 'documentfrontDoc_Front_1_blob.jpg' => :front, | ||
| 'Doc_Selfie_1_blob.jpg' => :selfie, |
There was a problem hiding this comment.
these are the expected file names as per our socure rep (it wasn't in the documentation when i was doing this, but they did say they would add it)
| image_errors = { image_request: [:network_error] } | ||
| end | ||
| else | ||
| images = {} |
There was a problem hiding this comment.
this is technically not necessary, as nil will splat as of ruby 3.4, but i think it's a little clearer/easier to reason about
Co-authored-by: Mitchell Henke <mitchell.henke@gsa.gov>
2 participants
🎫 Ticket
!21
🛠 Summary of changes
Socure's IAL2 flow was added before we anticipated, so this is a first crack of including the attempts api idv-document-upload-submitted event in socure's IAL2 flow.
I followed the patterns that already existed for fetching and translating Socure responses, so hopefully the structure of that work is sound.
Some considerations:
this code (as written) is single-threaded, meaning that it will hold up the user's flow. we should consider moving it asynchronously, as requesting and unzipping zip archives can be expensive, and will likely make a user impatient
we have to make some decisions about what to do if we are unable to retrieve the images.
the
SocureDocvResultsJob.performis fired when Socure transmits aDOCUMENTS_UPLOADEDwebhook eventType. Because of this, I think we can assume that the images exist and have been uploaded, but we still have to worry about network failures.questions to answer:
how do we handle retrying?
do we:
what kind of indication of a failure do we return with the event?
The upload submitted was a success or a failure based on the client response -- we should not present the event as a failure just because we were unable to retrieve the images. in this PR, I am including a
{ image_request: [:network_error] }failure reason if we are unable to retrieve the images. does this seem sufficient?