Adjust response code for SMS reply #2325
Conversation
**Why**: 4xx-class errors caused by random incoming messages would clutter log output. **How**: Adjust the response code.
app/controllers/sms_controller.rb
Outdated
| head :forbidden | ||
| # Invalid requests don't require a response for now, and 4xx | ||
| # errors from random incoming messages junk up the logs | ||
| head :ok |
There was a problem hiding this comment.
I think we may want to render a 403 here under a lot of circumstances, if for example the signature on the request is incorrect or our app thinks the request is malformed. Otherwise those errors won't be reported to us.
**Why**: 4xx-class errors caused by random incoming messages would clutter log output. **How**: Adjust the response code, vary based on error type.
| @@ -44,7 +36,11 @@ def process_failure(result) | |||
| result.to_h | |||
| ) | |||
|
|
|||
| head :forbidden | |||
| if [email protected]_valid? | |||
There was a problem hiding this comment.
Maybe instead of signature_valid?, we could do something like this:
if @message.unsupported_message_type?
head :ok
else
head :forbidden
end
...since what we really want is render a 200 when the message type is unsupported, and error in all other cases.
There was a problem hiding this comment.
I like the general approach, but that method feels a little contrived to serve this particular case. I'm trying to think of a good way to address the concern but with a better method. (I think the concept of 'valid' seems clearer and more standardized.)
There was a problem hiding this comment.
I think the important things is that we not swallow an error here. Currently, this would swallow an error for missing fields in the request.
There was a problem hiding this comment.
I was misreading how this works in the message class. This looks like it works.
Why: 4xx-class errors caused by random
incoming messages would clutter log output.
How: Adjust the response code.
Hi! Before submitting your PR for review, and/or before merging it, please
go through the following checklist:
For DB changes, check for missing indexes, check to see if the changes
affect other apps (such as the dashboard), make sure the DB columns in the
various environments are properly populated, coordinate with devops, plan
migrations in separate steps.
For route changes, make sure GET requests don't change state or result in
destructive behavior. GET requests should only result in information being
read, not written.
For encryption changes, make sure it is compatible with data that was
encrypted with the old code.
For secrets changes, make sure to update the S3 secrets bucket with the
new configs in all environments.
Do not disable Rubocop or Reek offenses unless you are absolutely sure
they are false positives. If you're not sure how to fix the offense, please
ask a teammate.
When reading data, write tests for nil values, empty strings,
and invalid formats.
When calling
redirect_toin a controller, use_url, not_path.When adding user data to the session, use the
user_sessionhelperinstead of the
sessionhelper so the data does not persist beyond the user'ssession.
When adding a new controller that requires the user to be fully
authenticated, make sure to add
before_action :confirm_two_factor_authenticated.