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

रूट गार्ड वास्तव में क्या हल करते हैं (और क्या नहीं)

रूट गार्ड एक काम अच्छी तरह करते हैं: वे नेविगेशन को कंट्रोल करते हैं। वे तय करते हैं कि कोई किसी रूट में जा सकता है या नहीं, और अगर नहीं तो उन्हें कहाँ भेजा जाए। इससे UX बेहतर होता है, लेकिन यह सुरक्षा का ही पर्याय नहीं है।

मेन्यू आइटम छिपाना सिर्फ एक संकेत है, असली ऑथराइज़ेशन नहीं। लोग फिर भी URL टाइप कर सकते हैं, डीप लिंक पर रिफ्रेश कर सकते हैं, या बुकमार्क खोल सकते हैं। अगर आपकी एकमात्र सुरक्षा "बटन दिखाई नहीं देता" है, तो आपकी कोई सुरक्षा नहीं है।

गार्ड उन जगहों पर चमकते हैं जहाँ आप चाहते हैं कि ऐप कंसिस्टेंट रहे जबकि उन पेजों को ब्लॉक किया जाए जो नहीं दिखने चाहिए—जैसे admin एरियाज़, इंटर्नल टूल्स, या रोल-आधारित कस्टमर पोर्टल।

गार्ड आपकी मदद करते हैं:

• रेंडर होने से पहले पेज ब्लॉक करना
• लॉगिन या किसी सुरक्षित डिफ़ॉल्ट पर रीडायरेक्ट करना
• टूटे हुए व्यू की बजाय साफ़ 401/403 स्क्रीन दिखाना
• अनचाही नेविगेशन लूप्स से बचना

जो गार्ड नहीं कर सकते वह यह है कि वे अकेले डेटा की रक्षा कर दें। अगर कोई API संवेदनशील डेटा ब्राउज़र को लौटाता है, तो कोई यूजर उस एंडपॉइंट को डायरेक्ट कॉल कर सकता है (या dev tools में रिस्पॉन्स देख सकता है) भले ही पेज ब्लॉक हो। असली ऑथराइज़ेशन सर्वर पर भी होना चाहिए।

एक अच्छा लक्ष्य दोनों पक्षों को कवर करना है: पेज ब्लॉक करें और डेटा भी ब्लॉक करें। अगर एक सपोर्ट एजेंट एक admin-only रूट खोलता है, तो गार्ड नेविगेशन रोक दे और “Access denied” दिखाए। अलग से, आपका बैकएंड admin-only API कॉल्स को अस्वीकार करे ताकि प्रतिबंधित डेटा कभी वापस न आए।

एक सरल रोल और परमीशन्स मॉडल चुनें

ऐक्सेस कंट्रोल तब उलझ जाता है जब आप लंबी रोल सूची से शुरू करते हैं। शुरू में एक छोटा सेट रखें जिसे लोग असल में समझें, और फिर केवल तब फाइनर permissions जोड़ें जब आपको वास्तविक दर्द महसूस हो।

एक व्यावहारिक विभाजन है:

• Roles यह बताते हैं कि कोई व्यक्ति आपके ऐप में कौन है।
• Permissions यह बताते हैं कि वे क्या कर सकते हैं।

अधिकांश इंटर्नल टूल्स के लिए तीन रोल काफी कवर करते हैं:

• admin: यूज़र्स और सेटिंग्स मैनेज करें, सभी डेटा देखें
• support: कस्टमर रिकॉर्ड और प्रतिक्रियाएँ संभाले, लेकिन सिस्टम सेटिंग्स नहीं देखें
• viewer: अनुमोदित स्क्रीन पर केवल पढ़ने की पहुँच

शुरू में तय करें कि रोल कहाँ से आते हैं। टोकन क्लेम्स (JWT) गार्ड्स के लिए तेज़ होते हैं पर तब तक stale हो सकते हैं जब तक रिफ्रेश न हो। ऐप स्टार्ट पर यूजर प्रोफ़ाइल फ़ेच करना हमेशा current रहता है, लेकिन आपके गार्ड्स को तब तक इंतजार करना चाहिए जब तक वह रिक्वेस्ट पूरा न हो जाए।

अपनी रूट क़िस्मों को भी स्पष्ट रूप से अलग रखें: public रूट (सभी के लिए खुले), authenticated रूट (session चाहिए), और restricted रूट (रोल या permission चाहिए)।

रूट meta के साथ एक्सेस नियम परिभाषित करें

एक्सेस व्यक्त करने का सबसे साफ़ तरीका है कि उसे खुद रूट पर घोषित करें। Vue Router आपको प्रत्येक रूट रिकॉर्ड पर एक meta ऑब्जेक्ट अटैच करने देता है ताकि आपके गार्ड बाद में उसे पढ़ सकें। इससे नियम उन पेजों के पास रहते हैं जिन्हें वे प्रोटेक्ट करते हैं।

एक सरल meta स्वरूप चुनें और पूरे ऐप में उस पर टिके रहें।

const routes = [
  {
    path: "/admin",
    component: () =\u003e import("@/pages/AdminLayout.vue"),
    meta: { requiresAuth: true, roles: ["admin"] },
    children: [
      {
        path: "users",
        component: () =\u003e import("@/pages/AdminUsers.vue"),
        // inherits requiresAuth + roles from parent
      },
      {
        path: "audit",
        component: () =\u003e import("@/pages/AdminAudit.vue"),
        meta: { permissions: ["audit:read"] },
      },
    ],
  },
  {
    path: "/tickets",
    component: () =\u003e import("@/pages/Tickets.vue"),
    meta: { requiresAuth: true, permissions: ["tickets:read"], readOnly: true },
  },
]

नेस्टेड रूट्स के लिए तय करें कि नियम कैसे मिलेंगे। ज़्यादातर ऐप्स में children को parent requirements विरासत में मिलनी चाहिए। अपने गार्ड में हर मैच किए गए रूट रिकॉर्ड की जाँच करें (केवल to.meta नहीं) ताकि parent नियम स्किप न हों।

एक छोटी सी डिटेल जो बाद में समय बचाती है: “देख सकते हैं” और “संपादित कर सकते हैं” में फर्क करें। एक रूट support और admins दोनों के लिए दिख सकता है, लेकिन edits support के लिए disable होने चाहिए। meta में readOnly: true फ़्लैग UI व्यवहार को चला सकता है (actions disable करना, destructive बटन छुपाना) बिना यह समझाए कि यह सुरक्षा है।

ऑथ स्टेट तैयार रखें ताकि गार्ड विश्वसनीय काम करें

ज़्यादातर गार्ड बग एक समस्या से आते हैं: गार्ड तब चलता है जब ऐप अभी यह नहीं जानता कि यूजर कौन है।

ऑथ को एक छोटे स्टेट मशीन की तरह ट्रीट करें और उसे सिंगल सोर्स ऑफ़ ट्रुथ बनाएँ। आप तीन स्पष्ट स्टेट चाहते हैं:

• unknown: ऐप अभी शुरू हुआ है, session अभी चेक नहीं हुआ
• logged out: session चेक पूरा हुआ, कोई वैध यूजर नहीं
• logged in: यूजर लोड हो गया, roles/permissions उपलब्ध हैं

नियम: जब तक ऑथ unknown है roles न पढ़ें। यही तरीका है जिससे आप प्रोटेक्टेड स्क्रीन का फ्लैश या लॉगिन पर अचानक रीडायरेक्ट देखते हैं।

सेशन रिफ्रेश कैसे काम करेगा, तय करें

एक रिफ्रेश रणनीति चुनें और उसे predictable रखें (उदाहरण: एक टोकन पढ़ें, एक "who am I" एंडपॉइंट कॉल करें, यूजर सेट करें)।

एक स्थिर पैटर्न कुछ इस तरह दिखता है:

• ऐप लोड पर, auth को unknown पर सेट करें और एक सिंगल रिफ्रेश रिक्वेस्ट शुरू करें
• गार्ड्स को तभी resolve करें जब रिफ्रेश खत्म हो जाए (या टाइमआउट हो)
• यूजर को मेमोरी में cache करें, route meta में नहीं
• विफलता पर, auth को logged out पर सेट करें
• एक ready प्रॉमिस (या समान) एक्सपोज़ करें जिसे गार्ड await कर सकें

एक बार यह मौजूद हो जाए, गार्ड लॉजिक सरल रहता है: auth के ready होने का इंतजार करें, फिर एक्सेस तय करें।

चरण-दर-चरण: रूट-लेवल ऑथराइज़ेशन लागू करें

एक साफ़ तरीका यह है कि अधिकांश नियम एक ग्लोबल गार्ड में रखें, और पर-रूट गार्ड केवल तभी इस्तेमाल करें जब किसी रूट को सच में स्पेशल लॉजिक की ज़रूरत हो।

1) एक ग्लोबल beforeEach गार्ड जोड़ें

// router/index.js
router.beforeEach(async (to) =\u003e {
  const auth = useAuthStore()

  // Step 2: wait for auth initialization when needed
  if (!auth.ready) await auth.init()

  // Step 3: check authentication, then roles/permissions
  if (to.meta.requiresAuth \u0026\u0026 !auth.isAuthenticated) {
    return { name: 'login', query: { redirect: to.fullPath } }
  }

  const roles = to.meta.roles
  if (roles \u0026\u0026 roles.length \u003e 0 \u0026\u0026 !roles.includes(auth.userRole)) {
    return { name: 'forbidden' } // 403
  }

  // Step 4: allow navigation
  return true
})

यह अधिकतर मामलों को कवर कर देता है बिना चेक्स को कॉम्पोनेंट्स में फैलाए।

जब beforeEnter बेहतर फिट है

beforeEnter तब उपयोग करें जब नियम वास्तव में रूट-विशिष्ट हो, जैसे “केवल टिकट का मालिक यह पेज खोल सकता है” और यह to.params.id पर निर्भर करता है। इसे छोटा रखें और वही auth स्टोर reuse करें ताकि व्यवहार कंसिस्टेंट रहे।

सुरक्षित रीडायरेक्ट्स बिना सुरक्षा छेद खोले

रीडायरेक्ट्स आपकी एक्सेस कंट्रोल को चुपचाप उलट सकते हैं अगर आप उन्हें ट्रस्ट कर लें।

आम पैटर्न यह है: जब यूजर लॉग आउट हो, उन्हें login पर भेजो और returnTo क्वेरी पैरामीटर शामिल करो। लॉगिन के बाद, उसे पढ़ो और वहाँ नेविगेट करो। जोखिम है open redirects (यूज़र्स को अनचाहे जगह भेजना) और लूप्स।

व्यवहार सरल रखें:

• लॉग-आउट यूज़र्स को Login भेजें और returnTo को करंट पाथ पर सेट करें।
• लॉग-इन पर परंतु अनऑथराइज़्ड यूज़र्स को समर्पित Forbidden पेज पर भेजें (Login नहीं)।
• केवल आंतरिक returnTo मानों को ही अनुमति दें जिन्हें आप पहचानते हैं।
• एक लूप चेक जोड़ें ताकि आप कभी उसी जगह पर रीडायरेक्ट न करें।

const allowedReturnTo = (to) =\u003e {
  if (!to || typeof to !== 'string') return null
  if (!to.startsWith('/')) return null
  // optional: only allow known prefixes
  if (!['/app', '/admin', '/tickets'].some(p =\u003e to.startsWith(p))) return null
  return to
}

router.beforeEach((to) =\u003e {
  if (!auth.isReady) return false

  if (!auth.isLoggedIn \u0026\u0026 to.name !== 'Login') {
    return { name: 'Login', query: { returnTo: to.fullPath } }
  }

  if (auth.isLoggedIn \u0026\u0026 !canAccess(to, auth.user) \u0026\u0026 to.name !== 'Forbidden') {
    return { name: 'Forbidden' }
  }
})

नेविगेशन के दौरान प्रतिबंधित डेटा लीक से बचें

सबसे आसान लीक तब होता है जब आप यह जाने बिना डेटा लोड कर लेते हैं कि यूजर उसे देखने के लिए सक्षम है या नहीं।

Vue में यह अक्सर तब होता है जब पेज setup() में डेटा फेच करता है और राउटर गार्ड थोड़ी देर बाद चलता है। भले ही यूजर को रीडायरेक्ट कर दिया जाए, रिस्पॉन्स अभी भी किसी शेयर किए गए स्टोर में आ सकता है या स्क्रीन पर झलक सकता है।

एक सुरक्षित नियम है: पहले authorize करें, फिर load।

// router guard: authorize before entering the route
router.beforeEach(async (to) =\u003e {
  await auth.ready() // ensure roles are known
  const required = to.meta.requiredRole
  if (required \u0026\u0026 !auth.hasRole(required)) {
    return { name: 'forbidden' }
  }
})

तेज़ नेविगेशन में लेट रिक्वेस्ट्स का भी ध्यान रखें। रिक्वेस्ट्स को cancel करें (उदाहरण के लिए AbortController के साथ) या request id चेक करके लेट रिस्पॉन्स को ignore करें।

Caching एक और आम फंदा है। अगर आप "last loaded customer record" को ग्लोबल में स्टोर करते हैं, तो एक admin-only रिस्पॉन्स बाद में किसी non-admin को दिखाई दे सकता है जो वही स्क्रीन खोलता है। कैश को user id और role के द्वारा key करें, और logout पर संवेदनशील मॉड्यूल्स साफ़ करें (या जब roles बदलें तो)।

कुछ आदतें अधिकांश लीक रोकती हैं:

• संवेदनशील डेटा ऑथाराइज़ेशन कन्फर्म होने तक न फेच करें।
• कैश्ड डेटा को user और role द्वारा key करें, या पेज-लोकल रखें।
• जब रूट बदलता है तो इन-फ्लाइट रिक्वेस्ट्स cancel या ignore करें।

फ्रेंडली फॉलबैक: 401, 403, और नॉट फाउंड

"नहीं" रास्ते उतने ही महत्वपूर्ण हैं जितने "हाँ" रास्ते। अच्छे fallback पेज यूज़र्स को ओरिएंटेड रखते हैं और सपोर्ट रिक्वेस्ट्स घटाते हैं।

401: लॉगिन चाहिए (ऑथेंटिकेटेड नहीं)

401 का उपयोग तब करें जब यूजर साइन इन नहीं है। संदेश साधा रखें: जारी रखने के लिए उन्हें साइन इन करना होगा। अगर आप ओरिजिनल पेज पर लौटने का समर्थन कर रहे हैं, तो return path वैध है क्या यह वेरिफाई करें ताकि यह आपके ऐप के बाहर न जा सके।

403: एक्सेस अस्वीकृत (साइन इन है, पर अनुमति नहीं)

403 का उपयोग तब करें जब यूजर साइन इन है पर अनुमति नहीं है। संदेश न्यूट्रल रखें और संवेदनशील विवरणों के संकेत देने से बचें।

एक ठोस 403 पेज में आमतौर पर एक स्पष्ट शीर्षक ("Access denied"), एक वाक्य में स्पष्टीकरण, और एक सुरक्षित अगला कदम होता है (डैशबोर्ड पर वापस जाएँ, किसी एडमिन से संपर्क करें, या अगर सपोर्ट है तो अकाउंट स्विच करें)।

404: नहीं मिला

404 को 401/403 से अलग संभालें। अन्यथा लोग यह मानते हैं कि उन्हें अनुमति नहीं है जबकि पेज बस मौजूद नहीं है।

एक्सेस कंट्रोल टूटने वाले आम गलतियाँ

ज्यादातर एक्सेस कंट्रोल बग साधारण लॉजिक स्लिप्स होते हैं जो redirect loops, गलत पेज का फ्लैश, या यूज़र्स के फंसने के रूप में दिखते हैं।

आम अपराधी:

• छिपी UI को "सुरक्षा" समझना। हमेशा राउटर और API दोनों में रोल्स लागू करें।
• logout/login के बाद stale state से roles पढ़ना।
• अनऑथराइज़्ड यूज़र्स को किसी और प्रोटेक्टेड रूट पर redirect करना (तुरंत लूप)।
• रिफ्रेश पर "auth अभी लोड हो रही है" पल की अनदेखी करना।
• 401 और 403 को गलत तरीके से मिश्रित करना, जिससे यूज़र्स भ्रमित होते हैं।

एक यथार्थवादी उदाहरण: एक सपोर्ट एजेंट लॉग आउट करता है और उसी साझा कंप्यूटर पर एक admin लॉग इन करता है। अगर आपका गार्ड cached role पढ़ लेगा इससे पहले कि नया session कन्फर्म हो, तो आप admin को गलत तरीके से ब्लॉक कर सकते हैं या, इससे भी बुरा, थोड़ी देर के लिए ऐसी पहुँच दे सकते हैं जो नहीं होनी चाहिए।

शिप करने से पहले त्वरित चेकलिस्ट

एक छोटा पास करें जो उन क्षणों पर ध्यान केंद्रित करे जहाँ एक्सेस कंट्रोल आमतौर पर टूटता है: धीले नेटवर्क, एक्सपायर सत्र, और बुकमार्क किए गए URLs।

• हर प्रोटेक्टेड रूट में स्पष्ट meta requirements हों।
• गार्ड्स auth-loading स्टेट को हैंडल करें बिना प्रोटेक्टेड UI का फ्लैश किए।
• अनऑथराइज़्ड यूज़र्स को एक साफ़ 403 पेज पर भेजा जाए (कन्फ्यूज़िंग होम बाउंस नहीं)।
• कोई भी "return to" रीडायरेक्ट वेलिडेट किया गया हो और लूप न बना सके।
• संवेदनशील API कॉल्स केवल ऑथराइज़ेशन कन्फर्म होने के बाद ही रन हों।

फिर एक सीनारियो end-to-end टेस्ट करें: साइन आउट करके एक प्रोटेक्टेड URL नई टैब में खोलें, बेसिक यूजर के रूप में साइन इन करें, और पुष्टि करें कि आप या तो इच्छित पेज पर जाते हैं (अगर अनुमति है) या एक साफ़ 403 व अगला कदम देखते हैं।

उदाहरण: एक छोटे वेब ऐप में support बनाम admin एक्सेस

मान लीजिए एक हेल्पडेस्क ऐप है जिसमें दो रोल हैं: support और admin। Support टिकटों को पढ़ और जवाब दे सकता है। Admin भी यह कर सकता है, और उसके अलावा बिलिंग और कंपनी सेटिंग्स मैनेज कर सकता है।

• /tickets/:id support और admin दोनों के लिए अनुमति है
• /settings/billing सिर्फ़ admin के लिए अनुमति है

अब एक आम पल: एक support एजेंट पुराने बुकमार्क से /settings/billing का डीप लिंक खोलता है। गार्ड को पेज लोड होने से पहले रूट meta चेक करना चाहिए और नेविगेशन को ब्लॉक करना चाहिए। चूंकि यूजर लॉग इन है पर रोल नहीं है, उन्हें एक सुरक्षित फॉलबैक (403) पर भेजा जाना चाहिए।

दो संदेश मायने रखते हैं:

• Login required (401): “Please sign in to continue.”
• Access denied (403): “You do not have access to Billing Settings.”

जो नहीं होना चाहिए: billing कॉम्पोनेंट माउंट हो जाए, या billing डेटा थोड़ी देर के लिए फेच हो जाए।

मिड-सेशन रोल चेंज भी एक एज केस है। अगर किसी को प्रमोट या डाउनग्रेड किया जाता है, तो मेन्यू पर निर्भर न रहें। नेविगेशन पर roles दोबारा चेक करें और तय करें कि आप active पेजेस को कैसे हैंडल करेंगे: जब प्रोफ़ाइल बदले तो auth स्टेट रिफ्रेश करें, या रोल चेंज detect करके उन पेजों से redirect कर दें जो अब अनुमत नहीं हैं।

अगले कदम: एक्सेस नियमों को maintainable रखें

एक बार गार्ड्स काम कर जाएँ, बड़ा जोखिम drift है: एक नया रूट बिना meta के शिप हो जाता है, एक रोल का नाम बदला जाता है, और नियम inconsistent हो जाते हैं।

अपने नियमों को एक छोटा टेस्ट प्लान बनाकर रखें जिसे आप हर बार नया रूट जोड़ने पर चला सकें:

• Guest के रूप में: प्रोटेक्टेड रूट खोलें और पुष्टि करें कि आप partial content देखें बिना login पर नहीं पहुँचे।
• User के रूप में: एक पेज खोलें जिसे आप एक्सेस नहीं कर सकते और पुष्टि करें कि आपको स्पष्ट 403 मिलता है।
• Admin के रूप में: address bar से कॉपी किए गए डीप लिंक आज़माएँ।
• हर रोल के लिए: प्रोटेक्टेड रूट पर रिफ्रेश करें और पुष्टि करें कि परिणाम स्थिर है।

अगर आप एक अतिरिक्त safety net चाहते हैं, तो एक dev-only view या console आउटपुट जोड़ें जो रूट्स और उनके meta requirements की सूची दिखाए, ताकि मिसिंग नियम तुरंत दिख जाएँ।

अगर आप internal tools या पोर्टल AppMaster (appmaster.io) के साथ बना रहे हैं, तो आप वही अप्रोच लागू कर सकते हैं: Vue3 UI में रूट गार्ड्स को नेविगेशन पर केंद्रित रखें, और permissions को वहीं लागू करें जहाँ बैकएंड लॉजिक और डेटा रहते हैं।

एक सुधार चुनें और उसे end-to-end लागू करें: डेटा-फ़ेच गेटिंग कड़ा करें, 403 पेज सुधारें, या रीडायरेक्ट हैंडलिंग लॉक डाउन करें। छोटे फिक्स ही वे होते हैं जो अधिकांश वास्तविक दुनिया की एक्सेस बग्स रोकते हैं।