எனது Next.js Auth Matcher-ஐ மூன்று முறை தவறாக அமைத்துவிட்டேன்
Next.js 16-இல் proxy.ts எவ்வாறு செயல்படுகிறது என்பதைப் புரிந்துகொள்வதற்கு முன்பு, நான் மூன்று புராஜெக்ட்களைச் சிதைத்துவிட்டேன்.
அந்தப் பிழை அமைதியாக இருந்தது. லாக்ஸோ (logs), எச்சரிக்கைகளோ (warnings) அல்லது பிழைகளோ (errors) இல்லை. வெறும் தவறான ரீடைரக்ட்கள் (redirects) மற்றும் பாதுகாப்பு இடைவெளிகள் மட்டுமே இருந்தன.
நீங்கள் Next.js 16-க்கு அப்டேட் செய்கிறீர்கள் என்றால், வெறும் codemod-ஐ மட்டும் இயக்கிவிட்டுப் போய்விடாதீர்கள். நீங்கள் இந்த மூன்று விஷயங்களைச் சரிபார்க்க வேண்டும்.
இடமாற்றப் பொறி (The Migration Trap)
Next.js, middleware.ts என்பதை proxy.ts என மாற்றியுள்ளது. இது வெறும் பெயரில் செய்யப்பட்ட மாற்றம் மட்டுமல்ல.
- middleware.ts, Edge runtime-இல் இயங்கியது. அதில் மட்டுப்படுத்தப்பட்ட crypto ஆதரவு மட்டுமே இருந்தது.
- proxy.ts இயல்பாகவே Node.js runtime-இல் இயங்குகிறது. இதில் முழுமையான crypto ஆதரவு உள்ளது.
நீங்கள் codemod இல்லாமல் உங்கள் பேக்கேஜை (package) கைமுறையாகப் புதுப்பித்தால், உங்கள் பழைய middleware.ts கோப்பு இன்னும் அங்கேயே இருக்கலாம். அது சரியாக கம்பைல் (compile) ஆகும். TypeScript சோதனைகளையும் (checks) ஏற்கும். ஆனால் அது எதையும் செய்யாது. உங்கள் ரூட்கள் (routes) தடுக்கப்படாது. உங்கள் ரீடைரக்ட்கள் (redirects) செயல்படாது.
இந்த மூன்று விஷயங்களை கைமுறையாகச் சரிபார்க்கவும்:
- proxy.ts உங்கள் புராஜெக்ட் ரூட்டில் (project root) இருக்க வேண்டும்.
- எக்ஸ்போர்ட் செய்யப்பட்ட (exported) பங்க்ஷனின் பெயர் proxy என்று இருக்க வேண்டும்.
- middleware.ts நீக்கப்பட வேண்டும்.
Matcher இடைவெளி (The Matcher Gap)
ஆத் (auth) அமைப்புகள் பெரும்பாலும் தோல்வியடைவது matcher-இல் தான்.
உங்கள் matcher மிகவும் பரந்ததாக (broad) இருந்தால், proxy ஒவ்வொரு CSS மற்றும் இமேஜ் ஃபைலிலும் இயங்கும். இது முடிவில்லாத ரீடைரக்ட் லூப்களை (infinite redirect loops) உருவாக்கும்.
உங்கள் matcher மிகவும் குறுகியதாக (narrow) இருந்தால், நீங்கள் ஒரு பாதுகாப்புத் துளையை (security hole) உருவாக்குகிறீர்கள்.
ஒரு ரூட் உங்கள் matcher-இல் இல்லை என்றால், proxy ஒருபோதும் இயங்காது. ஒரு பயனர் அந்த ரூட்டிற்குத் தனது சொந்த ஹெடர்களை (headers) அனுப்ப முடியும். உங்கள் Server Component அந்த ஹெடர்களை நம்பினால், ஒரு தாக்குதல் நடத்துபவர் (attacker) யாராக வேண்டுமானாலும் போலத் தோன்றலாம்.
தீர்வு: ஹெடர்களை (Headers) நம்பாதீர்கள்
நான் கஷ்டப்பட்டுப் புரிந்துகொண்ட பாடம்: proxy மூலம் அனுப்பப்படும் ஹெடர்களை (headers) மட்டும் நம்பிவிடாதீர்கள்.
இரண்டு அடுக்கு அணுகுமுறையைப் (two-layer approach) பயன்படுத்துங்கள்:
- நெட்வொர்க் எல்லையில் (network boundary) proxy ஒரு வேகமான நுழைவாயிலாகச் செயல்படுகிறது.
- Server Component, ரெண்டர் செய்யும் நேரத்தில் (render time) நேரடியாக குக்கீயிலிருந்து (cookie) JWT-ஐச் சரிபார்க்கிறது.
இந்த இரண்டாவது சரிபார்ப்பு அந்த இடைவெளியை மூடுகிறது. matcher ஒரு ரூட்டைத் தவறவிட்டாலும், Server Component அந்தத் தவறான பயனரைக் கண்டறிந்துவிடும். இது சில மில்லிசெகண்ட் தாமதத்தை (latency) ஏற்படுத்தினாலும், ஒரு பெரிய பாதுகாப்புத் தோல்வியைத் தடுக்கிறது.
சுருக்கமான சரிபார்ப்புப் பட்டியல் (Summary Checklist):
- auth-க்காக proxy.ts-ஐப் பயன்படுத்தவும்.
- முழுமையான crypto ஆதரவிற்காக Node.js runtime-ஐப் பயன்படுத்தவும்.
- ஹெடர்களை (headers) request-இல் அமைக்கவும், response-இல் அல்ல.
- எப்போதும் Server Components-க்குள் JWT-ஐச் சரிபார்க்கவும்.