Permission-Aware Route Fallbacks
Send people somewhere useful when a page exists but they cannot open it.
What it adds
Access denials that distinguish why the user was blocked and route them to something they can actually do.
What your agent is told to do
5
What your agent is told to do
5-
1
Enumerate the reasons a route can be refused: signed out, expired session, wrong workspace, insufficient role, suspended account, unpaid plan.
-
2
Give each its own response and its own next action. Sign in, switch workspace, request access, contact an admin, and upgrade are all different fixes.
-
3
For sensitive resources, return the same not-found response whether the record is missing or merely forbidden, so existence is not disclosed.
-
4
Capture the intended destination before redirecting to sign-in and return the user there afterwards.
-
5
Do NOT render a blank page or bounce to the dashboard with no explanation. Silent redirects read as bugs and generate support tickets.
Edge cases it handles
7
Edge cases it handles
7- A validated return URL only. An open redirect parameter is a phishing vector, so reject anything not internal to the app.
- Redirect loops happen when the fallback destination is itself forbidden. Cap the chain and fall through to a guaranteed-safe page.
- An expired session on a POST must not lose the user's input. Preserve it or tell them plainly that it was not saved.
- Do not leak record names, counts, or workspace details in the denial message for resources the user cannot see.
- API and page routes need different responses. A fetch must get a status code, not an HTML sign-in page.
- Where a request-access flow exists, route the user into it rather than dead-ending at 'forbidden'.
- Deep links shared between colleagues in different workspaces should offer to switch workspace rather than simply refusing.
Definition of done
8
Definition of done
8- Each denial reason produces a distinct response with a specific next action.
- Sensitive forbidden resources are indistinguishable from missing ones.
- The intended destination survives sign-in and is validated as internal before use.
- No route chain can loop; a guaranteed-safe fallback always terminates it.
- API requests receive status codes rather than redirects to HTML.
- Denial messages disclose nothing about the resource itself.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Upload Malware Scanning
Upload Malware Scanning
Quarantine uploaded files until they are known safe.
What it does
A quarantine lifecycle for uploads: every new file is unreachable until scanned, with defined handling for scanner failures and infected results.
How it works
- 1 Give every upload an explicit scan state — pending, clean, infected, or error — and default it to pending the moment the bytes land.
- 2 Make pending and infected files unreachable from every access path in the app, including admin views, previews, thumbnails, and any signed URL. A quarantine with one exception is not a quarantine.
- 3 Scan asynchronously and update the state; do not block the upload request on the scanner.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/upload-malware-scanning
Rate Limiting
Rate Limiting
Stop one client from ruining it for everyone.
What it does
Throttling on the endpoints that get abused: auth, search, exports, and public forms.
How it works
- 1 Identify the endpoints worth protecting: sign-in, sign-up, password reset, search, exports, and anything unauthenticated.
- 2 Limit by a stable identifier — user ID where signed in, IP otherwise. Be aware IP is shared behind NAT and proxies.
- 3 Return 429 with a Retry-After header. Do not silently drop the request.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/rate-limiting
Password Generator
Password Generator
Offer a strong password in one click wherever someone sets or changes credentials.
What it does
A generate control on password fields that produces a strong value, shows it, and hands it to the user safely.
How it works
- 1 Add the control to every place a password is set: sign-up, password change, password reset completion, and any admin screen that provisions credentials for someone else.
- 2 Generate the value in the browser using the platform's cryptographic random source. The value must never be produced on the server or sent anywhere.
- 3 Reveal the generated password by default so the user can record it, and offer a regenerate control beside it. A hidden generated password that the user cannot see is a password they will immediately reset.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/password-generator
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.