-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LG-11189 Count successful doc auth proofing towards the rate limit #9370
LG-11189 Count successful doc auth proofing towards the rate limit #9370
Conversation
Prior to this commit we reset the doc auth rate limiter on success. This was done to prevent users from being rate limited after successfully completing a step. The logic that caused that issue was addressed in #9343. This commit starts counting successful attempts to towards the rate limit. This protects our vendors from abuse and makes it easier for us to make this step re-entrant to support the back button. changelog: Improvements, Rate Limiting, The idv doc auth rate limiter was modified to rate limit on successful doc auth attempts as well as on failed doc auth proofing attempts
76aa8fe
to
63248fb
Compare
@@ -5,7 +5,7 @@ class DocumentCaptureController < ApplicationController | |||
include IdvStepConcern | |||
include StepIndicatorConcern | |||
|
|||
before_action :confirm_not_rate_limited | |||
before_action :confirm_not_rate_limited, except: [:update] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we still rate-limiting update somewhere? Otherwise, is it possible for someone to post unlimited updates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the specs you linked cover the update case. Do we want to add a line that checks that the rate limiter is limited after that final successful attempt here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, the update case for doc auth is interesting because it does not actually submit any data. It checks for the doc auth result and advances if it exist. It does not result in a vendor call. That is done by Idv::ImageUploadsController
within Idv::ApiImageUploadForm
. We do not need to consider the rate limiter in the update action for Idv::DocumentCaptureController
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The above said, I think a line in the feature spec is reasonable and not too expensive. I'll add one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, amazingly succinct! Recommend adding a spec line as already commented.
In the previous commit, we were looking to prevent the `capture_doc_status_controller` from setting the rate limit too early. In this commit, we are instead removing the logic to even look at rate limiting here, since [as Dawei pointed out](#10538 (comment)), and as I found [a past discussion for](#9370 (comment)), this code should never be reached if rate limited.
Prior to this commit we reset the doc auth rate limiter on success. This was done to prevent users from being rate limited after successfully completing a step. The logic that caused that issue was addressed in #9343.
This commit starts counting successful attempts to towards the rate limit. This protects our vendors from abuse and makes it easier for us to make this step re-entrant to support the back button.