Conversation
# Conflicts: # app/services/doc_auth_mock/doc_auth_mock_client.rb # app/services/idv/steps/doc_auth_base_step.rb
| def error_json(reason) | ||
| { | ||
| status: 'error', | ||
| message: reason, | ||
| } | ||
| end |
There was a problem hiding this comment.
What status code are we returning in the error case? Is it still going to be 200 OK ?
Asking because it's something where we should probably want the status code to match the response status here, and in doing so, we could perform success / error handling on the basis of status code alone. i.e. we wouldn't need status at all, if the HTTP status code is enough of a signal.
|
I merged in master in 2bb4deb to bring the branch back up to date, resolving conflicts with some of the new logging changes (#4001, #4007), and to preemptively address an issue I'd encountered in starting to wire up the front-end to the new endpoint (#4013). I see some test failures related to the logging changes, which I'm unclear yet if are due to an incompatibility of the changes, or an error on my part in resolving the conflicts. I pushed a few changes in ad271a0 and d6fda5f based on my prior feedback, incorporating the CSRF token management into the existing upload context, in a way that allows the upload implementation to receive the token as an argument automatically. d6fda5f replaces the stubbed upload implementation with a real one, using this new endpoint: The form now sends and receives real data 🎉 |
app/javascript/app/document-capture/components/acuant-capture.jsx
Outdated
Show resolved
Hide resolved
**Why**: @ironman5366 introduced this pattern in that PR. It is very helpful for moving to the API. It can stands on its own and cleans things up. I moved the changes to this PR to help decompose that one a bit.
**Why**: @ironman5366 introduced this pattern in that PR. It is very helpful for moving to the API. It can stands on its own and cleans things up. I moved the changes to this PR to help decompose that one a bit.
**Why**: PropTypes were removed in favor of TypeScript-validated JSDoc See: #4043
| nil | ||
| end | ||
|
|
||
| def check_content_type(request) |
There was a problem hiding this comment.
I marked my original comment as resolved, but flagging @zachmargolis's comment at #3985 (comment) for follow-up.
Also should we 415 for this? https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415
**Why**: Type-checking for free
| api_upload = flow_session['api_upload'] | ||
| response = (api_upload && api_upload['documents']) || post_form_images |
There was a problem hiding this comment.
We can take advantage of Hash#dig here I think:
| api_upload = flow_session['api_upload'] | |
| response = (api_upload && api_upload['documents']) || post_form_images | |
| response = flow_session.dig('api_upload', 'documents') || post_form_images |
| selfie = selfie_image ? selfie_image.read : nil | ||
| post_images(front_image.read, back_image.read, selfie) |
There was a problem hiding this comment.
We can do the nil-safe operator (or .try but I think rubocop prefers nil-safe these days)
| selfie = selfie_image ? selfie_image.read : nil | |
| post_images(front_image.read, back_image.read, selfie) | |
| post_images(front_image.read, back_image.read, selfie_image&.read) |
| end | ||
|
|
||
| def handle_response(response) | ||
| if response.to_h[:success] |
There was a problem hiding this comment.
usually our response objects have .success?
| if response.to_h[:success] | |
| if response.success? |
| 'front': 'front_image', | ||
| 'back': 'back_image', | ||
| 'selfie': 'selfie_image', |
There was a problem hiding this comment.
you can drop the quotes on these keys, they're still symbols (and same for the others in this file)
| 'front': 'front_image', | |
| 'back': 'back_image', | |
| 'selfie': 'selfie_image', | |
| front: 'front_image', | |
| back: 'back_image', | |
| selfie: 'selfie_image', |
| def check_image_fields(request) | ||
| data = request.body.read | ||
| @front_image = data['front'] | ||
| @back_image = data['back'] | ||
| @selfie_image = data['selfie'] | ||
| 'Missing image keys' unless [@front_image, @back_image, @selfie_image].all? | ||
| end |
There was a problem hiding this comment.
This has a side effect of setting the instance variables, so I think the name check_ is a little misleading.... honestly, the keys are straightforward I would consider not even setting them as instance variables at all and just checking for their presence
| steps = %i[check_content_type check_image_fields] | ||
| steps.each do |step| | ||
| err = method(step).call(request) | ||
| return error_json(err) if err | ||
| end | ||
| nil |
There was a problem hiding this comment.
With only two steps.... I don't think this is a great use for this level of dynamic behavior, there are a few alternatives I would prefer (in order of most to least preferred)
-
Let's make a Form object -- we do this is many other controllers, make a form object that performs the validations and returns useful error structures the controllers know how to render (LMK if you need a more detailed example)
-
Move these into before actions, so that way they can just render and stop the chain (instead of having a loop to check for errors and stop)
before_action :check_content_type, only: [:upload] before_action :check_image_fields, only[:upload]
-
Just call the methods directly:
error = check_content_type(request) || check_image_fields(request) error_json(err) ir err
| post '/api/sms/receive' => 'sms#receive' | ||
|
|
||
| # Image upload API for doc auth | ||
| post '/api/verify/upload' => 'idv/image_upload#upload' |
There was a problem hiding this comment.
Sometimes we try to stick to built-in rails method names/actions to be "RESTful"1 as much as we can, WDYT of renaming this to #create?
- I think "RESTful" is kind of a garbage term and can mean anything... in this case I'm just saying let's use the default names in rails for CRUD verbs
|
@aduth this is starting to diverge from |
Sure, that's fine with me 👍 |

This creates an API endpoint that images can be asynchronously uploaded to, to fulfill the Document Capture step.
The API endpoint is at
/api/verify/upload, and it accepts a POST containing the JSON attributesfront,back, andselfie. In this first version, it returns just a status of eithersuccessorerror, and a stringmessagewhich is an explanation of that status.