ನಾನು Next.js 16 ನೊಂದಿಗೆ ಮೂರು ದುಬಾರಿ Auth ತಪ್ಪುಗಳನ್ನು ಮಾಡಿದೆ

ನಾನು ಮೂರು ವಿಭಿನ್ನ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ proxy.ts matcher ಅನ್ನು ತಪ್ಪಾಗಿ ಮಾಡಿದೆ.

ಅತ್ಯಂತ ಕೆಟ್ಟ ವಿಷಯವೇನಂದರೆ? ಯಾವುದೇ ದೋಷಗಳು (errors) ಇರಲಿಲ್ಲ. ಯಾವುದೇ ಎಚ್ಚರಿಕೆಗಳು (warnings) ಇರಲಿಲ್ಲ. ಯಾವುದೇ ಲಾಗ್‌ಗಳು (logs) ಇರಲಿಲ್ಲ. ಭದ್ರತಾ ಲೋಪಗಳು (security holes) ಕಂಡುಬರುವವರೆಗೆ ಎಲ್ಲವೂ ಪರಿಪೂರ್ಣವಾಗಿ ಕಾಣುತ್ತಿತ್ತು.

Next.js 16, middleware.ts ಅನ್ನು proxy.ts ಗೆ ಬದಲಾಯಿಸಿದೆ. ಇದು ಕೇವಲ ಹೆಸರಿನ ಬದಲಾವಣೆಯಲ್ಲ. ನೀವು ರಿಕ್ವೆಸ್ಟ್‌ಗಳನ್ನು (requests) ನಿರ್ವಹಿಸುವ ರೀತಿಯಲ್ಲಿನ ಮೂಲಭೂತ ಬದಲಾವಣೆ ಇದಾಗಿದೆ.

ನಿಮ್ಮ Auth ವ್ಯವಸ್ಥೆಯು ಕುಸಿಯದಂತೆ ತಡೆಯಲು ನೀವು ತಿಳಿದುಕೊಳ್ಳಲೇಬೇಕಾದ ವಿಷಯಗಳು ಇಲ್ಲಿವೆ.

ಹೊಸ ನಿಯಮಗಳು Middleware ಗೊಂದಲಮಯವಾಗಿತ್ತು. ಡೆವಲಪರ್‌ಗಳು ಇದನ್ನು ಡೇಟಾಬೇಸ್ ಕರೆಗಳು (database calls) ಮತ್ತು ಭಾರೀ ಲಾಜಿಕ್ (heavy logic) ಗಾಗಿ ಬಳಸುತ್ತಿದ್ದರು. ಅದು ಅದರ ಕೆಲಸವಲ್ಲ.

Proxy ಎಂಬುದು ನೆಟ್‌ವರ್ಕ್ ಗಡಿಯಲ್ಲಿ (network boundary) ಇರುತ್ತದೆ. ಇದು ನಿಮ್ಮ ರೂಟ್‌ಗಳಿಗೆ (routes) ತಲುಪುವ ಮೊದಲೇ ರಿಕ್ವೆಸ್ಟ್‌ಗಳನ್ನು ತಡೆಯುತ್ತದೆ.

ಮೌನ ವೈಫಲ್ಯ ನೀವು codemod ಬಳಸದೆ Next.js ಅನ್ನು ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಿದರೆ, ನಿಮ್ಮ ಹಳೆಯ middleware.ts ಫೈಲ್ ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಉಳಿಯಬಹುದು. ಅದು TypeScript ಚೆಕ್‌ಗಳನ್ನು ಪಾಸು ಮಾಡುತ್ತದೆ. ಅದು ಸರಿಯಾಗಿ ಕಾಂಪೈಲ್ (compile) ಆಗುತ್ತದೆ.

ಆದರೆ ಅದು ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.

ನಿಮ್ಮ ರಿಡೈರೆಕ್ಟ್‌ಗಳು (redirects) ಕಾರ್ಯಗತಗೊಳ್ಳುವುದಿಲ್ಲ. ನಿಮ್ಮ Auth ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೇವಲ ಭದ್ರತಾ ಪದರವನ್ನು (security layer) ಮೌನವಾಗಿ ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ.

ಈ ಮೂರು ವಿಷಯಗಳನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ಪರಿಶೀಲಿಸಿ:

ಮ್ಯಾಚರ್ ಟ್ರ್ಯಾಪ್ ಹೆಚ್ಚಿನ Auth ಸೆಟಪ್‌ಗಳು matcher ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ತಪ್ಪಾಗುತ್ತವೆ. ನೀವು ಸ್ಟ್ಯಾಟಿಕ್ ಫೈಲ್‌ಗಳನ್ನು (static files) ಹೊರಗಿಡದಿದ್ದರೆ, ಪ್ರತಿಯೊಂದು CSS ಮತ್ತು JS ಫೈಲ್ ಮೇಲೆ proxy ಚಲಿಸುತ್ತದೆ. ಇದು ಅಸೆಟ್‌ಗಳ (assets) ಮೇಲೆ ಅನಂತ ರಿಡೈರೆಕ್ಟ್ ಲೂಪ್‌ಗಳನ್ನು (infinite redirect loops) ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಹೊರಗಿಡಲು negative lookahead ಬಳಸಿ:

ಎಚ್ಚರಿಕೆ: ಕೇವಲ ಹೆಡರ್ಸ್‌ಗಳನ್ನು (Headers) ನಂಬಬೇಡಿ ಇಲ್ಲಿ ನಾನು ತಪ್ಪು ಮಾಡಿದೆ.

Proxy ರಿಕ್ವೆಸ್ಟ್‌ನಲ್ಲಿ x-user-id ನಂತಹ ಹೆಡರ್‌ಗಳನ್ನು ಸೆಟ್ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ Server Components ಇವುಗಳನ್ನು headers() ಮೂಲಕ ಓದುತ್ತವೆ.

ನಿಮ್ಮ matcher ನಲ್ಲಿ ಅಂತರವಿದ್ದರೆ (gap), ಬಳಕೆದಾರರು ತಮ್ಮದೇ ಆದ x-user-id ಹೆಡರ್ ಅನ್ನು ಕಳುಹಿಸಬಹುದು. Proxy ಸೆಟ್ ಮಾಡಿದ ಹೆಡರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಕಳುಹಿಸಿದ ಹೆಡರ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು Server Component ಗೆ ತಿಳಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ.

ದಾಳಿಕೋರರು (Attacker) ಮ್ಯಾಚ್ ಆಗದ ರೂಟ್‌ನಲ್ಲಿ ಬಳಕೆದಾರರ ಐಡಿಯನ್ನು (user ID) spoof ಮಾಡಬಹುದು. ಅವರು ಡೇಟಾವನ್ನು ನೋಡಲು ಸಾಧ್ಯವಾಗದಿರಬಹುದು, ಆದರೆ ಅವರಿಗೆ ಇರಬಾರದ ಅನುಮತಿಗಳನ್ನು (permissions) ಅವರು ಪಡೆಯಬಹುದು.

ಪರಿಹಾರ: Proxy ಎಂಬುದು ನಿಮ್ಮ ವೇಗದ ಗೇಟ್ (fast gate). ಇದು ಎಡ್ಜ್‌ನಲ್ಲಿ (edge) ಭಾರೀ ಕೆಲಸಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

ಆದರೆ ನೀವು ನಿಮ್ಮ Server Components ಒಳಗೆ JWT ಅನ್ನು ಮತ್ತೊಮ್ಮೆ ಪರಿಶೀಲಿಸಬೇಕು.

ರೆಡಂಡನ್ಸಿ ಎಂದರೆ ಭದ್ರತೆ.

𝗦𝗼𝘂𝗿𝗰𝗲: https://dev.to/shubhradev/i-got-the-proxyts-matcher-wrong-for-three-projects-before-i-understood-why-4e5c