feat: implement 401 and 403 status pages - #223
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds client-side 401 and 403 status pages with navigation actions and terminal-style diagnostic panels. ChangesAuthentication status pages
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/app/unauthorized.tsx`:
- Around line 42-50: Update the Button/Link composition in
src/app/unauthorized.tsx lines 42-50 and src/app/forbidden.tsx lines 32-40: make
Button use asChild and place the existing Link inside it, preserving the current
href, styling, icon, and label at both sites.
- Line 9: Wire the Unauthorized component in src/app/unauthorized.tsx and the
Forbidden component in src/app/forbidden.tsx into the protected Next.js 16 route
handlers/components: call unauthorized() for missing authentication and
forbidden() for permission failures, and add path coverage proving each
corresponding UI renders. Both cited files require no direct UI changes beyond
preserving their existing components.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 8ad5fdd6-29c8-43d9-8dc5-8badbf1ad9bd
📒 Files selected for processing (2)
src/app/forbidden.tsxsrc/app/unauthorized.tsx
| import { Home, LogIn, Lock, ShieldQuestion } from "lucide-react"; | ||
| import { Button } from "@/components/ui/Button"; | ||
|
|
||
| export default function Unauthorized() { |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
fd -HI -E node_modules '^next\.config\.(js|mjs|ts)$|^package\.json$' . \
-x sh -c 'echo "=== $1 ==="; sed -n "1,220p" "$1"' sh {}
rg -n -C 4 --glob '*.{ts,tsx,js,jsx}' \
'\b(unauthorized|forbidden)\s*\(' srcRepository: BeyteFlow/ReadmeGenAI
Length of output: 1621
🌐 Web query:
Next.js 16 authentication middleware unauthorized forbidden app directory documentation
💡 Result:
In Next.js 16, the middleware.ts file has been deprecated and replaced by proxy.ts [1][2]. This file acts as a centralized request interceptor that runs before your application routes are processed [1][3]. ### Key Authentication Changes in Next.js 16 * Renaming & Runtime: Use the codemod npx @next/codemod@canary middleware-to-proxy to rename middleware.ts to proxy.ts and update the export to proxy [2][4]. Unlike previous versions, proxy.ts now defaults to the Node.js runtime [1][4]. * Architecture Shift: Next.js 16 enforces a "thin proxy" architecture [2]. The proxy.ts file should be limited to optimistic checks (e.g., verifying a session cookie to perform fast redirects) [2][5][6]. It should not perform database lookups or complex cryptographic verification [2][5]. * Security Layers: Because proxy.ts does not protect internal invocations (such as Server Actions or internal server-side fetches), you must perform authoritative authorization within your application logic [7][5][6]. ### Handling Unauthorized and Forbidden States To manage unauthorized or forbidden access within your App Router application, use the dedicated unauthorized() and forbidden() functions [8][9]. * unauthorized() (401): Throws an error to render your unauthorized.js UI [9]. This is best used when a user is not authenticated and needs to be prompted to log in [9]. * forbidden() (403): Throws an error to render your forbidden.js UI [8]. This is best used when a user is authenticated but lacks the specific permissions required for the requested resource [8]. These functions can be invoked in Server Components, Server Actions, and Route Handlers [8][9]. Because they work by throwing an error, they must be called within the render path [8][9]. ### Recommended Pattern 1. Proxy Layer: Use proxy.ts to check for the presence of a session cookie and redirect unauthenticated users to a login page [10][5][6]. 2. Data Access Layer (DAL): Centralize your session verification logic (e.g., verifySession()) in a DAL [11][5]. Use React's cache() function to deduplicate these checks during a single request [11][10][5]. 3. Component/Handler Level: Invoke your verifySession() and check permissions inside your Server Components and Route Handlers, using unauthorized() or forbidden() when requirements are not met [11][10][5][8][9]. This approach ensures that your application is secure regardless of how a route is accessed [5][6].
Citations:
- 1: https://nextjs.org/docs/app/api-reference/file-conventions/proxy
- 2: https://beyondit.blog/blogs/nextjs-16-1-migration-middleware-to-proxy
- 3: https://auth0.com/blog/handling-auth-nextjs16-with-server-actions-middleware/
- 4: https://hamzashabbir.dev/article/nextjs-16-middleware-to-proxy-migration-auth-edge
- 5: https://www.thanosk.eu/deep-dives/authentication-architecture-nextjs-16
- 6: https://juanchi.dev/en/blog/nextjs-16-middleware-authorization-patterns-race-conditions
- 7: https://shubhra.dev/tutorials/nextjs-16-authentication-3-layer-security
- 8: https://nextjs.org/docs/app/api-reference/functions/forbidden
- 9: https://nextjs.org/docs/app/api-reference/functions/unauthorized
- 10: https://workos.com/blog/nextjs-app-router-authentication-guide-2026
- 11: https://nextjs.org/docs/app/guides/authentication
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== tracked file list candidates ==="
git ls-files | rg '(^src/app/(unauthorized|forbidden)\.tsx$|(^src/|test|spec|vitest|package|next\.config|middleware|proxy)\.' || true
echo "=== proxy/middleware/search ==="
rg -n -C 3 --glob '*.{ts,tsx,js,jsx}' '\b(unauthorized|forbidden|verifySession|hasPermission|forbidden\s*\(|unauthorized\s*\()' . || trueRepository: BeyteFlow/ReadmeGenAI
Length of output: 393
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== tracked candidate files ==="
git ls-files | grep -E '(^src/app/(unauthorized|forbidden)\.tsx$|^src/|test|spec|vitest|package\.json|next\.config|middleware|proxy)' || true
echo "=== auth-related symbols ==="
rg -n -C 3 --glob '*.{ts,tsx,js,jsx}' '\b(unauthorized|forbidden|proxy|verifySession|hasPermission)\b' . || trueRepository: BeyteFlow/ReadmeGenAI
Length of output: 1434
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== unauthorized.tsx ==="
cat -n src/app/unauthorized.tsx || true
echo "=== forbidden.tsx ==="
cat -n src/app/forbidden.tsx || true
echo "=== protected route candidates ==="
for f in src/app/generate/\[\ repo\']/page.tsx src/app/docs/page.tsx src/app/generate/page.tsx src/app/examples/page.tsx; do
if [ -f "$f" ]; then
echo "--- $f ---"
sed -n '1,240p' "$f"
fi
done
echo "=== Next config/package relevant ==="
sed -n '1,80p' next.config.ts
sed -n '1,120p' package.jsonRepository: BeyteFlow/ReadmeGenAI
Length of output: 17208
Wire the 401/403 UI into protected route failures.
src/app/unauthorized.tsx and src/app/forbidden.tsx are only UI components. Call unauthorized() for missing authentication and forbidden() for permission failures in the protected Next.js 16 route handlers/components, and add path coverage so the tests prove each UI renders on the corresponding failure.
📍 Affects 2 files
src/app/unauthorized.tsx#L9-L9(this comment)src/app/forbidden.tsx#L8-L8
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/app/unauthorized.tsx` at line 9, Wire the Unauthorized component in
src/app/unauthorized.tsx and the Forbidden component in src/app/forbidden.tsx
into the protected Next.js 16 route handlers/components: call unauthorized() for
missing authentication and forbidden() for permission failures, and add path
coverage proving each corresponding UI renders. Both cited files require no
direct UI changes beyond preserving their existing components.
|
Regarding the wiring comment: these 401/403 pages are registered Next.js 16 special files (\unauthorized.tsx/ orbidden.tsx) and render whenever \unauthorized()\ / \ orbidden()\ is invoked from a Server Component or Route Handler. There are currently no protected pages in the app — the /generate\ flow intentionally supports anonymous README generation for public repos, so guarding it would break that product flow. The pages are ready to render once an auth-enforced route is introduced. The nested-interactive fix has been pushed. |
|
@coderabbitai review |
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
1 participant
Closes #36
Adds placeholder 401 (unauthorized) and 403 (forbidden) error pages in the App Router, ready for the now-present GitHub authentication system.
Changes
ot-found.tsx\ / \error.tsx\ (black bg, gradient headline, terminal panel, responsive CTA buttons).
Notes
ot-found.tsx) and 500 (\error.tsx) pages already render correctly with consistent layout.
pm run lint, \ sc --noEmit, and a full
ext build.