West Midlands | 26 March SDC | Iswat Bello | Sprint 1 | Purple Forest/bug report/Extra long blooms

[Iswanna]

Learners, PR Template

Self checklist

• I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
• My changes meet the requirements of the task
• I have tested my changes
• My changes follow the style guide

Changelist

This PR fixes a bug whereby the application allowed blooms (posts) longer than 280 characters to be saved to the database. While the frontend had validation, the backend lacked a "security guard" to prevent direct API requests or scripts from bypassing the limit.

The Problem: The application was only validating bloom length on the frontend. This allowed scripts (like populate.py) or direct API requests to save blooms longer than 280 characters, breaking the business rules.

The Fix:

• Added a MAX_BLOOM_LENGTH constant (280) to the backend.
• Updated the send_bloom function in endpoints.py to check the length of the incoming content.
• The backend now returns a 400 Bad Request if the bloom exceeds the limit.

Verification:

• I performed a factory reset of the database and ran populate.py.
• Confirmed that the backend successfully rejected the oversized bloom from the script with a 400 error.
• Verified via DBeaver that the invalid bloom was not saved to the database.

[nedssoft]

Excellent thinking, Iswat — spotting that the 280-char limit was only enforced on the frontend and could be bypassed by a script or direct API call is exactly the "never trust the client" instinct that makes a good backend dev. 👏 Pulling the limit into a named MAX_BLOOM_LENGTH and returning a clean 400 is spot on, with thorough DB verification.

One small thing to mull (not blocking): your message says a bloom must be "less than 280 characters", but your check > MAX_BLOOM_LENGTH actually lets exactly 280 through. Is 280 meant to be allowed or rejected — and does the wording match what the code does?

[Iswanna]

Excellent thinking, Iswat — spotting that the 280-char limit was only enforced on the frontend and could be bypassed by a script or direct API call is exactly the "never trust the client" instinct that makes a good backend dev. 👏 Pulling the limit into a named MAX_BLOOM_LENGTH and returning a clean 400 is spot on, with thorough DB verification.

One small thing to mull (not blocking): your message says a bloom must be "less than 280 characters", but your check > MAX_BLOOM_LENGTH actually lets exactly 280 through. Is 280 meant to be allowed or rejected — and does the wording match what the code does?

Thank you so much @nedssoft, for the feedback.
You are completely right about the boundary logic. My intention was to allow exactly 280 characters (to match the frontend), which is why I used the > operator in the code. However, I see now that my previous message was technically incorrect compared to the logic.
I have just pushed a commit to update the message to: Bloom must not exceed {MAX_BLOOM_LENGTH} characters. This now accurately describes the behaviour of the code.