Verified against Replit Agent · 2026-07-29
Add real authentication to an app that never had any
A Replit Agent brief for retrofitting real login onto an app that's been running open, with an explicit route-by-route access audit and a stated decision about who owns the data that existed before users did.
The prompt
Ready to copy — highlighted parts are example details you can swap.
the warehouse StockDesk tool currently has no authentication at all — anyone who has the URL can use it fully. Add real login so only the 6-person warehouse team, invite-only, no public sign-up can access it, without breaking whatever already works today. CURRENT STATE A Flask app with a Postgres database, three routes (products, orders, stock movements), currently reachable by anyone with the Repl URL — no login screen exists at all AUTH APPROACH Use Flask-Login with password hashing via werkzeug's built-in generate_password_hash, plus an invite-only signup gated by a one-time invite token stored in the database rather than hand-rolling password hashing, session tokens, or a login flow from scratch — authentication is one of the few areas where "write it yourself" is a real security liability, not just extra work, since a subtly wrong hashing scheme or a predictable session token is the kind of mistake that's invisible until it's exploited. If Flask-Login with password hashing via werkzeug's built-in generate_password_hash, plus an invite-only signup gated by a one-time invite token stored in the database needs an external provider's client ID and secret, walk me through getting them and store them as Replit Secrets, never inline in the code. MIGRATING EXISTING DATA All 340 existing StockMovement rows have no created_by value today since there was no user concept when they were created — since the app previously had no concept of a user who owns anything, decide explicitly what happens to data created before this change: does it get assigned to a designated first admin account, does it become globally visible to any logged-in user, or does it need a one-time manual assignment step. State which approach you're taking and why, rather than silently picking one. ACCESS CONTROL Every existing route and every existing background job that touches user data needs to be checked, not just the ones that were obviously "supposed" to be protected — walk through the app's actual route list and background jobs and confirm each one either requires a logged-in session or is deliberately, explicitly still public, naming which is which. A route that's accidentally still reachable without login after this change is a bug, not an acceptable gap, even if nobody happens to hit it during testing. SESSION BEHAVIOR Sessions should expire after 12 hours of inactivity, and a logout action must actually invalidate the session server-side, not just clear a cookie client-side — a client-side-only logout leaves the session usable by anyone who still has the old cookie value. ROLLOUT Before this goes live for real users, confirm what happens to anyone currently using the app without an account — do they get logged out and asked to sign up, or is there a grace period. State this explicitly rather than leaving existing users to hit an unexplained wall. OUTPUT 1. Every route/job audited, marked protected or intentionally public. 2. The existing-data migration decision and why. 3. The rollout plan for current users. 4. A short note on what you'd still want a human to double-check by hand before this goes live — a static audit of route protection is not the same thing as an actual penetration test of the finished login flow.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The explicit "use a real library, never hand-rolled" instruction matters more here than in most feature-add prompts because authentication is a domain where a plausible-looking custom implementation — a self-written token scheme, a homegrown password comparison — can be subtly and catastrophically wrong in ways that don't show up in normal testing. A non-constant-time password comparison, a session token generated from a predictable source, a hashing scheme without a per-user salt are all mistakes an agent given a vague "add login" instruction with no library named has no particular reason to avoid, since something that looks correct and runs correctly for the one test case it tries reads as done. The mandatory route-by-route audit targets the actual risk profile of adding auth to an app retrofitted after the fact rather than designed with it from day one. A fresh app built with auth from the start typically has every route behind a consistent middleware by construction; bolting auth onto an app that's been running open for a while means each existing route was written with no access-control assumption at all, so it's genuinely easy — for the agent or for a human — to protect the obvious routes like the main dashboard while missing a secondary API endpoint the frontend calls internally, or a background job that also touches the same data, neither of which "look like" login pages and are therefore easy to overlook without a forced, explicit walk-through of the full list. Requiring an explicit decision about ownership of pre-existing, user-less data addresses a gap that has no natural default. Rows created before any concept of "user" existed genuinely have no correct owner to infer, and an agent that isn't asked to decide explicitly will often pick the path of least resistance — leaving created_by null forever, or silently assigning everything to whichever account happens to be first in the table — either of which is a real decision with real consequences for who can see or edit that historical data, and it deserves to be made deliberately rather than as an unexamined side effect of the migration.
Verified against
Replit Agent Replit Agent (chat-based build mode in Replit) · 2026-07-29
Changelog
- 2026-07-29 — Initial publish, verified against Replit Agent with a full route-by-route access audit and an explicit pre-existing-data ownership decision.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
