Maison Retail tightens who gets to knock on its backend

A small, portable fix to the rule deciding which website is allowed to talk to the fork's server - and a quiet config trap it closes along the way.

securityinfrastructure

Web apps run on a kind of guest list: the browser only lets the approved front-end website exchange data with the back-end server. This fork rewrote that check to be both stricter and smarter. The old setup matched the approved address against incoming requests exactly, so an address written with a trailing slash - a near-invisible difference - could silently block the real front end and break the app for no obvious reason.

The new version cleans up both sides before comparing them, prints the approved address at startup so deployment problems are easier to trace, and clearly turns away anything that doesn't match. It's small, self-contained, and not tied to this fork's particular setup.

So what Anyone running or weighing a self-hosted legal-AI deployment will recognize this as the kind of quiet reliability-and-security fix worth copying.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from Maison-Retail-Management-International/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
a2a1cb23 Harden CORS origin matching and log allowed FRONTEND_URL at startup. Thomas GUILLEMAUD 2026-05-20 ↗ GitHub
Co-authored-by: Cursor <cursoragent@cursor.com>

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-560.md from inside the repo you want the changes in.

⬇ Download capture-thread-560.md