Use custom exception on params too deep error.#1837
Conversation
|
CI error seems unrelated, would it be possible to try restart? Btw. this is the middleware I was able to use to gracefully fail in my Rails app on this error. module MyApp::Middleware
class DeepParamsHandler
def initialize(app)
@app = app
end
def call(env)
begin
Rack::Request.new(env).params
status, headers, response = @app.call(env)
[status, headers, response]
rescue RangeError => e
[ 302, {'Location' =>"/500.html"}, [] ]
end
end
end
end |
|
Thanks @tenderlove. What do you think about backporting this to Rack 2.2.x? I can open PR if welcomed. |
|
@simi if the goal is to allow Rails apps to handle that, I think it is fine to backport. Please open the PR. |
|
@rafaelfranca that's my goal indeed. I'm on it. |
|
Since this is a user visible change, I would like to see an entry to the change log for this (as well as the backport). Thanks. |
|
@ioquatix changelog is definitely planned from my side. I have checked few other PRs and changelogs were not introduced, I wasn't sure when it is good time to add it. Sometimes maintainers do changelog update before the release on their own. :/ |
|
Yeah, and I'm also one to forgot to do it in the past. We should definitely aim for fully self-contained PRs where possible. For the backport it will need a clear explanation of any changes if there are compatibility trade offs, so it's a good time to introduce it. One challenge is that the changelog will have slightly different organisation in the backport but ideally we'd do that as part of the backport PR. |
|
I think consideration should be given to opening a See Vee Ee (sounded out because there are bots that scrape Github looking for the proper abbreviation). This issue appears to affect availability. |
|
Actually rack itself does nothing wrong. It just raises an error on problem as expected. But this error is not handled in Rails and thanks to the nature of the general nature being raised, it is hard to update Rails code to handle this now. Your proposal maybe will make sense later at Rails side. I'll ask once I'll open PR in there as well. |
|
That makes sense. Thanks for clarifying! |
Hello, I have been working on fixing some malicious requests causing server 500s responses at rails application.
There is list of default exceptions transformed into proper responses in Rails.
https://github.com/rails/rails/blob/926b803297c4bc529ee46296a7cd5cc02bb21100/actionpack/lib/action_dispatch/middleware/exception_wrapper.rb#L6-L24
As you can see, the other errors (
ParameterTypeErrorandInvalidParameterError) are already part of this list and they result into400 Bad requestresponse by default. But breaking the rackparam_depth_limitsetting results into general RubyRangeErrorexception currently and it is hard to recognise what's the cause (since any other code can raise this general Ruby exception) and that's (probably) the reason why it is not handled by default in Rails.I suggest to introduce Rack custom exception for this problem as well (inherited from originally used
RangeError) to be able to catch this easily. Next step (if approved) would be to add this exception to default Rails list as well. In the end I think it needs to be added in here - https://github.com/rails/rails/blob/926b803297c4bc529ee46296a7cd5cc02bb21100/actionpack/lib/action_dispatch/http/request.rb#L382-L384.It is hard to fix currently in the app, the only solution I was able to find out is to create simple middleware to read the params and handle the error in there.
Since the exception is inherited from the original one (and tests were passing with no change as well) I would to propose to backport this to 2.x series as well to be able to fix this as soon as possible.