This repository was archived by the owner on Sep 21, 2026. It is now read-only.
Conversation
The limit parameter in _get_limit() was passed directly to int() without error handling, causing an unhandled 500 error when a non-integer value like 'abc' or '' was provided. Changes: - Wrap int(limit) in try/except ValueError, returning 400 Bad Request - Add explicit check for non-positive values (limit < 1) - Remove redundant int() call on return statement Fixes the DoS concern noted in issue #310.
merlinorg
added a commit
to freezingsaddles/freezing
that referenced
this pull request
Sep 19, 2026
freezingsaddles/freezing-web#617 by velezf: ?limit= on the track endpoints went straight into int(), so anything that is not a number was a 500 with a traceback rather than a refusal. A negative one got through the check and reached SQL as a negative LIMIT, which was a 500 by another route. Both are 400s now, and the function returns the limit it validated instead of taking the minimum again. The rest of that pull request is repository furniture that the monorepo already has its own versions of. freezingsaddles/freezing-web#503 by obscurerichard: the beginning of year procedure never said to clear the activity and weather caches, so last season's cached responses carried into the new one. The script it calls is already here as deploy/bin/clear-cache-directories.sh. Checked against the running app: a non-numeric, empty, zero or negative limit is a 400 where it used to be a 500, a limit past TRACK_LIMIT_MAX is still a 400, and 1, the maximum itself and no limit at all still answer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
Thank you — this is a real fix and it has been carried into the monorepo at freezingsaddles/freezing#49, which is what deploys now. Closing here because this repository is no longer the one that ships. Sorry it sat for so long. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
_get_limit()inapi.pypassed the?limit=query parameter directlyto
int()without error handling. A non-integer value like?limit=abcor
?limit=caused an unhandledValueError, returning a 500 server errorinstead of a meaningful 400 Bad Request.
This also bypassed the
TRACK_LIMIT_MAXcheck entirely, creating a potentialDoS vector noted in issue #310.
Fix
int(limit)intry/except ValueError, returningabort(400)limit < 1)int()call on the return statementTesting
Tested locally with curl against a running dev server:
?limit=50→ 200 OK?limit=abc→ 400 Bad Request?limit=0→ 400 Bad Request