James Postadan | Oct2025-2 | Module Legacy Code | Sprint 1 | Extra long blooms - #4
Open
japostadan wants to merge 4 commits into
Open
James Postadan | Oct2025-2 | Module Legacy Code | Sprint 1 | Extra long blooms#4japostadan wants to merge 4 commits into
japostadan wants to merge 4 commits into
Conversation
The profile view wired the login handler to a click on a non-existent [data-action="proxy.php?url=https%3A%2F%2Fgithub.com%2Fjapostadan%2FModule-Legacy-Code%2Fpull%2Flogin"] element, so the login form rendered on a profile page had no submit handler. Submitting it triggered a native form POST to the static file server (501 on python http.server, 405 on nginx) instead of authenticating. - Wire the profile-page login form to its submit event, matching the home login view (lib uses handleLogin which preventDefaults). - Add a Playwright regression test: login -> view profile -> logout -> log back in from the profile page.
hashtagView called getBloomsByHashtag() without awaiting it. When the fetch resolved, state.updateState() dispatched a state-change event, which triggered handleRouteChange() → hashtagView() again → another fetch → infinite loop. destroy() on every iteration caused the visible blank flash. - Guard the fetch on state.currentHashtag so we only fetch when the hashtag actually changes; re-renders triggered by unrelated state-change events skip the fetch and just re-render from existing state. - Add Playwright regression tests: verifies exactly one fetch per navigation and that heading + blooms are visible and stable.
The frontend already enforces maxlength="280" on the textarea, but the POST /bloom endpoint had no server-side validation, so any client (curl, populate.py, etc.) could submit blooms of arbitrary length. AS's seeded bloom was 375 characters as a result. - Add BLOOM_MAX_LENGTH = 280 constant and reject content over the limit with a 400 and a descriptive error message, matching the pattern used for MINIMUM_PASSWORD_LENGTH in register(). - Trim AS's seeded bloom in populate.py to 246 chars so it stays valid. - Add backend/endpoints_test.py: three tests against the live backend — exactly-280 accepted, 281 rejected, error body contains "280".
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
🎯 Summary
populate.py(375 → 246 chars) so fresh seeds stay valid🧾 Changelist
POST /bloominendpoints.pyhad no server-side length validation. The frontend enforcesmaxlength="280"on the textarea, but any client bypassing the browser (curl,populate.py, scripts) could post blooms of arbitrary length. AS's seeded bloom was 375 characters as a result.BLOOM_MAX_LENGTH = 280constant and a length check insend_bloom()that returns{"success": false, "message": "Blooms must be 280 characters or fewer"}with HTTP 400 when exceeded. Pattern follows the existingMINIMUM_PASSWORD_LENGTHguard inregister().backend/endpoints_test.pyuses stdliburllib(no extra deps) and hits the real running backend. Three cases: 280-char bloom accepted (200), 281-char bloom rejected (400), rejected response body contains"280". Run withpython3 -m unittest endpoints_testfrombackend/.❓ Questions
VARCHAR(280)constraint be added to the schema as a second line of defence, or is the application-level check sufficient?🙌 Notes for Reviewers
docker compose up -d, thencurl -X POST http://localhost:3000/bloom -H "Authorization: Bearer <token>" -H "Content-Type: application/json" -d '{"content":"'"$(python3 -c "print('a'*281)")"'"}'— should return 400.docker compose down -v && docker compose up -dfollowed bydocker compose exec backend python populate.pywill reseed with the corrected data.