Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
The `DateHashParser` class is responsible for taking a hash containing keys of some combination of `day`, `month` and `year` and trying to return a full `Date` object. It is flexible enough to handle hashes where certain keys are missing, e.g. if the `year` key isn't present, it sets the value to be the current year. We've seen quite a few exceptions coming through from this class where it looks like somebody has been messing about with the query parameters in the URL, which are combined into a hash and sent through to this class for parsing. A (truncated) example request is: ``` /search/all?keywords=the&public_timestamp[from][day][]=17&public_timestamp[from][month]=7&public_timestamp[from][year]=1967 ``` Here we can see that `public_timestamp[from][day]` is an array value rather than a numeric value like `month` and `year`. This doesn't appear to be a legitimate bug caused by the frontend. Looking through the Sentry logs it's pretty clear somebody is manipulating the URL for some reason. So it makes sense to fix the bug in this class by flagging a date hash as invalid if any of the values don't respond to `to_i`. We're always expecting these values to be numeric so this feels like a valid assumption to make. The exception is raised in the constructor currently, where we call `transform_values(&:to_i)`, which blows up if a value is, for example, an array. Instead we'll extend the `any_non_positive_values?` method to check that the values both respond to `to_i` and are positive.
- Loading branch information