रोल-आधारित एक्सेस के लिए Vue 3 राउटिंग गार्ड — व्यावहारिक पैटर्न

रूट गार्ड वास्तव में क्या हल करते हैं (और क्या नहीं)\n\nरूट गार्ड एक काम अच्छी तरह करते हैं: वे नेविगेशन को कंट्रोल करते हैं। वे तय करते हैं कि कोई किसी रूट में जा सकता है या नहीं, और अगर नहीं तो उन्हें कहाँ भेजा जाए। इससे UX बेहतर होता है, लेकिन यह सुरक्षा का ही पर्याय नहीं है।\n\nमेन्यू आइटम छिपाना सिर्फ एक संकेत है, असली ऑथराइज़ेशन नहीं। लोग फिर भी URL टाइप कर सकते हैं, डीप लिंक पर रिफ्रेश कर सकते हैं, या बुकमार्क खोल सकते हैं। अगर आपकी एकमात्र सुरक्षा "बटन दिखाई नहीं देता" है, तो आपकी कोई सुरक्षा नहीं है।\n\nगार्ड उन जगहों पर चमकते हैं जहाँ आप चाहते हैं कि ऐप कंसिस्टेंट रहे जबकि उन पेजों को ब्लॉक किया जाए जो नहीं दिखने चाहिए—जैसे admin एरियाज़, इंटर्नल टूल्स, या रोल-आधारित कस्टमर पोर्टल।\n\nगार्ड आपकी मदद करते हैं:\n\n- रेंडर होने से पहले पेज ब्लॉक करना\n- लॉगिन या किसी सुरक्षित डिफ़ॉल्ट पर रीडायरेक्ट करना\n- टूटे हुए व्यू की बजाय साफ़ 401/403 स्क्रीन दिखाना\n- अनचाही नेविगेशन लूप्स से बचना\n\nजो गार्ड नहीं कर सकते वह यह है कि वे अकेले डेटा की रक्षा कर दें। अगर कोई API संवेदनशील डेटा ब्राउज़र को लौटाता है, तो कोई यूजर उस एंडपॉइंट को डायरेक्ट कॉल कर सकता है (या dev tools में रिस्पॉन्स देख सकता है) भले ही पेज ब्लॉक हो। असली ऑथराइज़ेशन सर्वर पर भी होना चाहिए।\n\nएक अच्छा लक्ष्य दोनों पक्षों को कवर करना है: पेज ब्लॉक करें और डेटा भी ब्लॉक करें। अगर एक सपोर्ट एजेंट एक admin-only रूट खोलता है, तो गार्ड नेविगेशन रोक दे और “Access denied” दिखाए। अलग से, आपका बैकएंड admin-only API कॉल्स को अस्वीकार करे ताकि प्रतिबंधित डेटा कभी वापस न आए।\n\n## एक सरल रोल और परमीशन्स मॉडल चुनें\n\nऐक्सेस कंट्रोल तब उलझ जाता है जब आप लंबी रोल सूची से शुरू करते हैं। शुरू में एक छोटा सेट रखें जिसे लोग असल में समझें, और फिर केवल तब फाइनर permissions जोड़ें जब आपको वास्तविक दर्द महसूस हो।\n\nएक व्यावहारिक विभाजन है:\n\n- Roles यह बताते हैं कि कोई व्यक्ति आपके ऐप में कौन है।\n- Permissions यह बताते हैं कि वे क्या कर सकते हैं।\n\nअधिकांश इंटर्नल टूल्स के लिए तीन रोल काफी कवर करते हैं:\n\n- admin: यूज़र्स और सेटिंग्स मैनेज करें, सभी डेटा देखें\n- support: कस्टमर रिकॉर्ड और प्रतिक्रियाएँ संभाले, लेकिन सिस्टम सेटिंग्स नहीं देखें\n- viewer: अनुमोदित स्क्रीन पर केवल पढ़ने की पहुँच\n\nशुरू में तय करें कि रोल कहाँ से आते हैं। टोकन क्लेम्स (JWT) गार्ड्स के लिए तेज़ होते हैं पर तब तक stale हो सकते हैं जब तक रिफ्रेश न हो। ऐप स्टार्ट पर यूजर प्रोफ़ाइल फ़ेच करना हमेशा current रहता है, लेकिन आपके गार्ड्स को तब तक इंतजार करना चाहिए जब तक वह रिक्वेस्ट पूरा न हो जाए।\n\nअपनी रूट क़िस्मों को भी स्पष्ट रूप से अलग रखें: public रूट (सभी के लिए खुले), authenticated रूट (session चाहिए), और restricted रूट (रोल या permission चाहिए)।\n\n## रूट meta के साथ एक्सेस नियम परिभाषित करें\n\nएक्सेस व्यक्त करने का सबसे साफ़ तरीका है कि उसे खुद रूट पर घोषित करें। Vue Router आपको प्रत्येक रूट रिकॉर्ड पर एक meta ऑब्जेक्ट अटैच करने देता है ताकि आपके गार्ड बाद में उसे पढ़ सकें। इससे नियम उन पेजों के पास रहते हैं जिन्हें वे प्रोटेक्ट करते हैं।\n\nएक सरल meta स्वरूप चुनें और पूरे ऐप में उस पर टिके रहें।\n\njs\nconst routes = [\n {\n path: \"/admin\",\n component: () =\u003e import(\"@/pages/AdminLayout.vue\"),\n meta: { requiresAuth: true, roles: [\"admin\"] },\n children: [\n {\n path: \"users\",\n component: () =\u003e import(\"@/pages/AdminUsers.vue\"),\n // inherits requiresAuth + roles from parent\n },\n {\n path: \"audit\",\n component: () =\u003e import(\"@/pages/AdminAudit.vue\"),\n meta: { permissions: [\"audit:read\"] },\n },\n ],\n },\n {\n path: \"/tickets\",\n component: () =\u003e import(\"@/pages/Tickets.vue\"),\n meta: { requiresAuth: true, permissions: [\"tickets:read\"], readOnly: true },\n },\n]\n\n\nनेस्टेड रूट्स के लिए तय करें कि नियम कैसे मिलेंगे। ज़्यादातर ऐप्स में children को parent requirements विरासत में मिलनी चाहिए। अपने गार्ड में हर मैच किए गए रूट रिकॉर्ड की जाँच करें (केवल to.meta नहीं) ताकि parent नियम स्किप न हों।\n\nएक छोटी सी डिटेल जो बाद में समय बचाती है: “देख सकते हैं” और “संपादित कर सकते हैं” में फर्क करें। एक रूट support और admins दोनों के लिए दिख सकता है, लेकिन edits support के लिए disable होने चाहिए। meta में readOnly: true फ़्लैग UI व्यवहार को चला सकता है (actions disable करना, destructive बटन छुपाना) बिना यह समझाए कि यह सुरक्षा है।\n\n## ऑथ स्टेट तैयार रखें ताकि गार्ड विश्वसनीय काम करें\n\nज़्यादातर गार्ड बग एक समस्या से आते हैं: गार्ड तब चलता है जब ऐप अभी यह नहीं जानता कि यूजर कौन है।\n\nऑथ को एक छोटे स्टेट मशीन की तरह ट्रीट करें और उसे सिंगल सोर्स ऑफ़ ट्रुथ बनाएँ। आप तीन स्पष्ट स्टेट चाहते हैं:\n\n- unknown: ऐप अभी शुरू हुआ है, session अभी चेक नहीं हुआ\n- logged out: session चेक पूरा हुआ, कोई वैध यूजर नहीं\n- logged in: यूजर लोड हो गया, roles/permissions उपलब्ध हैं\n\nनियम: जब तक ऑथ unknown है roles न पढ़ें। यही तरीका है जिससे आप प्रोटेक्टेड स्क्रीन का फ्लैश या लॉगिन पर अचानक रीडायरेक्ट देखते हैं।\n\n### सेशन रिफ्रेश कैसे काम करेगा, तय करें\n\nएक रिफ्रेश रणनीति चुनें और उसे predictable रखें (उदाहरण: एक टोकन पढ़ें, एक "who am I" एंडपॉइंट कॉल करें, यूजर सेट करें)।\n\nएक स्थिर पैटर्न कुछ इस तरह दिखता है:\n\n- ऐप लोड पर, auth को unknown पर सेट करें और एक सिंगल रिफ्रेश रिक्वेस्ट शुरू करें\n- गार्ड्स को तभी resolve करें जब रिफ्रेश खत्म हो जाए (या टाइमआउट हो)\n- यूजर को मेमोरी में cache करें, route meta में नहीं\n- विफलता पर, auth को logged out पर सेट करें\n- एक ready प्रॉमिस (या समान) एक्सपोज़ करें जिसे गार्ड await कर सकें\n\nएक बार यह मौजूद हो जाए, गार्ड लॉजिक सरल रहता है: auth के ready होने का इंतजार करें, फिर एक्सेस तय करें।\n\n## चरण-दर-चरण: रूट-लेवल ऑथराइज़ेशन लागू करें\n\nएक साफ़ तरीका यह है कि अधिकांश नियम एक ग्लोबल गार्ड में रखें, और पर-रूट गार्ड केवल तभी इस्तेमाल करें जब किसी रूट को सच में स्पेशल लॉजिक की ज़रूरत हो।\n\n### 1) एक ग्लोबल beforeEach गार्ड जोड़ें\n\njs\n// router/index.js\nrouter.beforeEach(async (to) =\u003e {\n const auth = useAuthStore()\n\n // Step 2: wait for auth initialization when needed\n if (!auth.ready) await auth.init()\n\n // Step 3: check authentication, then roles/permissions\n if (to.meta.requiresAuth \u0026\u0026 !auth.isAuthenticated) {\n return { name: 'login', query: { redirect: to.fullPath } }\n }\n\n const roles = to.meta.roles\n if (roles \u0026\u0026 roles.length \u003e 0 \u0026\u0026 !roles.includes(auth.userRole)) {\n return { name: 'forbidden' } // 403\n }\n\n // Step 4: allow navigation\n return true\n})\n\n\nयह अधिकतर मामलों को कवर कर देता है बिना चेक्स को कॉम्पोनेंट्स में फैलाए।\n\n### जब beforeEnter बेहतर फिट है\n\nbeforeEnter तब उपयोग करें जब नियम वास्तव में रूट-विशिष्ट हो, जैसे “केवल टिकट का मालिक यह पेज खोल सकता है” और यह to.params.id पर निर्भर करता है। इसे छोटा रखें और वही auth स्टोर reuse करें ताकि व्यवहार कंसिस्टेंट रहे।\n\n## सुरक्षित रीडायरेक्ट्स बिना सुरक्षा छेद खोले\n\nरीडायरेक्ट्स आपकी एक्सेस कंट्रोल को चुपचाप उलट सकते हैं अगर आप उन्हें ट्रस्ट कर लें।\n\nआम पैटर्न यह है: जब यूजर लॉग आउट हो, उन्हें login पर भेजो और returnTo क्वेरी पैरामीटर शामिल करो। लॉगिन के बाद, उसे पढ़ो और वहाँ नेविगेट करो। जोखिम है open redirects (यूज़र्स को अनचाहे जगह भेजना) और लूप्स।\n\nव्यवहार सरल रखें:\n\n- लॉग-आउट यूज़र्स को Login भेजें और returnTo को करंट पाथ पर सेट करें।\n- लॉग-इन पर परंतु अनऑथराइज़्ड यूज़र्स को समर्पित Forbidden पेज पर भेजें (Login नहीं)।\n- केवल आंतरिक returnTo मानों को ही अनुमति दें जिन्हें आप पहचानते हैं।\n- एक लूप चेक जोड़ें ताकि आप कभी उसी जगह पर रीडायरेक्ट न करें।\n\njs\nconst allowedReturnTo = (to) =\u003e {\n if (!to || typeof to !== 'string') return null\n if (!to.startsWith('/')) return null\n // optional: only allow known prefixes\n if (!['/app', '/admin', '/tickets'].some(p =\u003e to.startsWith(p))) return null\n return to\n}\n\nrouter.beforeEach((to) =\u003e {\n if (!auth.isReady) return false\n\n if (!auth.isLoggedIn \u0026\u0026 to.name !== 'Login') {\n return { name: 'Login', query: { returnTo: to.fullPath } }\n }\n\n if (auth.isLoggedIn \u0026\u0026 !canAccess(to, auth.user) \u0026\u0026 to.name !== 'Forbidden') {\n return { name: 'Forbidden' }\n }\n})\n\n\n## नेविगेशन के दौरान प्रतिबंधित डेटा लीक से बचें\n\nसबसे आसान लीक तब होता है जब आप यह जाने बिना डेटा लोड कर लेते हैं कि यूजर उसे देखने के लिए सक्षम है या नहीं।\n\nVue में यह अक्सर तब होता है जब पेज setup() में डेटा फेच करता है और राउटर गार्ड थोड़ी देर बाद चलता है। भले ही यूजर को रीडायरेक्ट कर दिया जाए, रिस्पॉन्स अभी भी किसी शेयर किए गए स्टोर में आ सकता है या स्क्रीन पर झलक सकता है।\n\nएक सुरक्षित नियम है: पहले authorize करें, फिर load।\n\njs\n// router guard: authorize before entering the route\nrouter.beforeEach(async (to) =\u003e {\n await auth.ready() // ensure roles are known\n const required = to.meta.requiredRole\n if (required \u0026\u0026 !auth.hasRole(required)) {\n return { name: 'forbidden' }\n }\n})\n\n\nतेज़ नेविगेशन में लेट रिक्वेस्ट्स का भी ध्यान रखें। रिक्वेस्ट्स को cancel करें (उदाहरण के लिए AbortController के साथ) या request id चेक करके लेट रिस्पॉन्स को ignore करें।\n\nCaching एक और आम फंदा है। अगर आप "last loaded customer record" को ग्लोबल में स्टोर करते हैं, तो एक admin-only रिस्पॉन्स बाद में किसी non-admin को दिखाई दे सकता है जो वही स्क्रीन खोलता है। कैश को user id और role के द्वारा key करें, और logout पर संवेदनशील मॉड्यूल्स साफ़ करें (या जब roles बदलें तो)।\n\nकुछ आदतें अधिकांश लीक रोकती हैं:\n\n- संवेदनशील डेटा ऑथाराइज़ेशन कन्फर्म होने तक न फेच करें।\n- कैश्ड डेटा को user और role द्वारा key करें, या पेज-लोकल रखें।\n- जब रूट बदलता है तो इन-फ्लाइट रिक्वेस्ट्स cancel या ignore करें।\n\n## फ्रेंडली फॉलबैक: 401, 403, और नॉट फाउंड\n\n"नहीं" रास्ते उतने ही महत्वपूर्ण हैं जितने "हाँ" रास्ते। अच्छे fallback पेज यूज़र्स को ओरिएंटेड रखते हैं और सपोर्ट रिक्वेस्ट्स घटाते हैं।\n\n### 401: लॉगिन चाहिए (ऑथेंटिकेटेड नहीं)\n\n401 का उपयोग तब करें जब यूजर साइन इन नहीं है। संदेश साधा रखें: जारी रखने के लिए उन्हें साइन इन करना होगा। अगर आप ओरिजिनल पेज पर लौटने का समर्थन कर रहे हैं, तो return path वैध है क्या यह वेरिफाई करें ताकि यह आपके ऐप के बाहर न जा सके।\n\n### 403: एक्सेस अस्वीकृत (साइन इन है, पर अनुमति नहीं)\n\n403 का उपयोग तब करें जब यूजर साइन इन है पर अनुमति नहीं है। संदेश न्यूट्रल रखें और संवेदनशील विवरणों के संकेत देने से बचें।\n\nएक ठोस 403 पेज में आमतौर पर एक स्पष्ट शीर्षक ("Access denied"), एक वाक्य में स्पष्टीकरण, और एक सुरक्षित अगला कदम होता है (डैशबोर्ड पर वापस जाएँ, किसी एडमिन से संपर्क करें, या अगर सपोर्ट है तो अकाउंट स्विच करें)।\n\n### 404: नहीं मिला\n\n404 को 401/403 से अलग संभालें। अन्यथा लोग यह मानते हैं कि उन्हें अनुमति नहीं है जबकि पेज बस मौजूद नहीं है।\n\n## एक्सेस कंट्रोल टूटने वाले आम गलतियाँ\n\nज्यादातर एक्सेस कंट्रोल बग साधारण लॉजिक स्लिप्स होते हैं जो redirect loops, गलत पेज का फ्लैश, या यूज़र्स के फंसने के रूप में दिखते हैं।\n\nआम अपराधी:\n\n- छिपी UI को "सुरक्षा" समझना। हमेशा राउटर और API दोनों में रोल्स लागू करें।\n- logout/login के बाद stale state से roles पढ़ना।\n- अनऑथराइज़्ड यूज़र्स को किसी और प्रोटेक्टेड रूट पर redirect करना (तुरंत लूप)।\n- रिफ्रेश पर "auth अभी लोड हो रही है" पल की अनदेखी करना।\n- 401 और 403 को गलत तरीके से मिश्रित करना, जिससे यूज़र्स भ्रमित होते हैं।\n\nएक यथार्थवादी उदाहरण: एक सपोर्ट एजेंट लॉग आउट करता है और उसी साझा कंप्यूटर पर एक admin लॉग इन करता है। अगर आपका गार्ड cached role पढ़ लेगा इससे पहले कि नया session कन्फर्म हो, तो आप admin को गलत तरीके से ब्लॉक कर सकते हैं या, इससे भी बुरा, थोड़ी देर के लिए ऐसी पहुँच दे सकते हैं जो नहीं होनी चाहिए।\n\n## शिप करने से पहले त्वरित चेकलिस्ट\n\nएक छोटा पास करें जो उन क्षणों पर ध्यान केंद्रित करे जहाँ एक्सेस कंट्रोल आमतौर पर टूटता है: धीले नेटवर्क, एक्सपायर सत्र, और बुकमार्क किए गए URLs।\n\n- हर प्रोटेक्टेड रूट में स्पष्ट meta requirements हों।\n- गार्ड्स auth-loading स्टेट को हैंडल करें बिना प्रोटेक्टेड UI का फ्लैश किए।\n- अनऑथराइज़्ड यूज़र्स को एक साफ़ 403 पेज पर भेजा जाए (कन्फ्यूज़िंग होम बाउंस नहीं)।\n- कोई भी "return to" रीडायरेक्ट वेलिडेट किया गया हो और लूप न बना सके।\n- संवेदनशील API कॉल्स केवल ऑथराइज़ेशन कन्फर्म होने के बाद ही रन हों।\n\nफिर एक सीनारियो end-to-end टेस्ट करें: साइन आउट करके एक प्रोटेक्टेड URL नई टैब में खोलें, बेसिक यूजर के रूप में साइन इन करें, और पुष्टि करें कि आप या तो इच्छित पेज पर जाते हैं (अगर अनुमति है) या एक साफ़ 403 व अगला कदम देखते हैं।\n\n## उदाहरण: एक छोटे वेब ऐप में support बनाम admin एक्सेस\n\nमान लीजिए एक हेल्पडेस्क ऐप है जिसमें दो रोल हैं: support और admin। Support टिकटों को पढ़ और जवाब दे सकता है। Admin भी यह कर सकता है, और उसके अलावा बिलिंग और कंपनी सेटिंग्स मैनेज कर सकता है।\n\n- /tickets/:id support और admin दोनों के लिए अनुमति है\n- /settings/billing सिर्फ़ admin के लिए अनुमति है\n\nअब एक आम पल: एक support एजेंट पुराने बुकमार्क से /settings/billing का डीप लिंक खोलता है। गार्ड को पेज लोड होने से पहले रूट meta चेक करना चाहिए और नेविगेशन को ब्लॉक करना चाहिए। चूंकि यूजर लॉग इन है पर रोल नहीं है, उन्हें एक सुरक्षित फॉलबैक (403) पर भेजा जाना चाहिए।\n\nदो संदेश मायने रखते हैं:\n\n- Login required (401): “Please sign in to continue.”\n- Access denied (403): “You do not have access to Billing Settings.”\n\nजो नहीं होना चाहिए: billing कॉम्पोनेंट माउंट हो जाए, या billing डेटा थोड़ी देर के लिए फेच हो जाए।\n\nमिड-सेशन रोल चेंज भी एक एज केस है। अगर किसी को प्रमोट या डाउनग्रेड किया जाता है, तो मेन्यू पर निर्भर न रहें। नेविगेशन पर roles दोबारा चेक करें और तय करें कि आप active पेजेस को कैसे हैंडल करेंगे: जब प्रोफ़ाइल बदले तो auth स्टेट रिफ्रेश करें, या रोल चेंज detect करके उन पेजों से redirect कर दें जो अब अनुमत नहीं हैं।\n\n## अगले कदम: एक्सेस नियमों को maintainable रखें\n\nएक बार गार्ड्स काम कर जाएँ, बड़ा जोखिम drift है: एक नया रूट बिना meta के शिप हो जाता है, एक रोल का नाम बदला जाता है, और नियम inconsistent हो जाते हैं।\n\nअपने नियमों को एक छोटा टेस्ट प्लान बनाकर रखें जिसे आप हर बार नया रूट जोड़ने पर चला सकें:\n\n- Guest के रूप में: प्रोटेक्टेड रूट खोलें और पुष्टि करें कि आप partial content देखें बिना login पर नहीं पहुँचे।\n- User के रूप में: एक पेज खोलें जिसे आप एक्सेस नहीं कर सकते और पुष्टि करें कि आपको स्पष्ट 403 मिलता है।\n- Admin के रूप में: address bar से कॉपी किए गए डीप लिंक आज़माएँ।\n- हर रोल के लिए: प्रोटेक्टेड रूट पर रिफ्रेश करें और पुष्टि करें कि परिणाम स्थिर है।\n\nअगर आप एक अतिरिक्त safety net चाहते हैं, तो एक dev-only view या console आउटपुट जोड़ें जो रूट्स और उनके meta requirements की सूची दिखाए, ताकि मिसिंग नियम तुरंत दिख जाएँ।\n\nअगर आप internal tools या पोर्टल AppMaster (appmaster.io) के साथ बना रहे हैं, तो आप वही अप्रोच लागू कर सकते हैं: Vue3 UI में रूट गार्ड्स को नेविगेशन पर केंद्रित रखें, और permissions को वहीं लागू करें जहाँ बैकएंड लॉजिक और डेटा रहते हैं।\n\nएक सुधार चुनें और उसे end-to-end लागू करें: डेटा-फ़ेच गेटिंग कड़ा करें, 403 पेज सुधारें, या रीडायरेक्ट हैंडलिंग लॉक डाउन करें। छोटे फिक्स ही वे होते हैं जो अधिकांश वास्तविक दुनिया की एक्सेस बग्स रोकते हैं।