13 सित॰ 2025·8 मिनट
ऐसे नेविगेशन मेनू जो अनुमतियाँ दिखाते हुए भी एक्सेस लागू करते हैं
अनुमतियों-सूचित नेविगेशन मेनू स्पष्टता बढ़ाते हैं, पर सुरक्षा बैकएंड पर रहनी चाहिए — रोल, नीतियों और सुरक्षित UI छिपाने के सरल तरीके जानें।
अनुमतियों-सूचित नेविगेशन मेनू स्पष्टता बढ़ाते हैं, पर सुरक्षा बैकएंड पर रहनी चाहिए — रोल, नीतियों और सुरक्षित UI छिपाने के सरल तरीके जानें।
जब लोग कहते हैं “बटन छिपाओ,” तो वे आमतौर पर दो बातों में से एक चाहते हैं: उन यूज़र्स के लिए अव्यवस्था घटाना जो किसी फ़ीचर का उपयोग नहीं कर सकते, या दुरुपयोग रोकना। फ्रंटेंड पर केवल पहला लक्ष्य यथार्थवादी है।
अनुमतियों-सूचित नेविगेशन मेनू मुख्यतः एक UX टूल हैं। ये किसी को ऐप खोलते ही यह समझने में मदद करते हैं कि वे क्या कर सकते हैं, बिना हर दूसरे क्लिक पर “Access denied” स्क्रीन का सामना किए। ये सपोर्ट लोड भी घटाते हैं क्योंकि users ऐसे कन्फ्यूज़ नहीं होंगे जैसे “मुझे इनवॉइस कहाँ अप्रूव करना है?” या “यह पेज क्यों एरर कर रहा है?”
UI छिपाना सुरक्षा नहीं है। यह स्पष्टता है।
यहाँ तक कि जिज्ञासु सहकर्मी भी अभी भी कर सकते हैं:
असल समस्या जो अनुमति-सचेत मेनू हल करते हैं वह ईमानदार मार्गदर्शन है। ये इंटरफ़ेस को यूज़र के काम, भूमिका और संदर्भ के अनुरूप रखते हैं, साथ ही यह स्पष्ट बना देते हैं जब कुछ उपलब्ध नहीं है।
एक अच्छा अंत-स्थिति कुछ इस तरह दिखती है:
उदाहरण: एक छोटे CRM में, एक Sales Rep को Leads और Tasks दिखने चाहिए, पर User Management नहीं। यदि वे फिर भी user management URL पेस्ट कर दें, तो पेज को fail-closed होना चाहिए, और सर्वर किसी भी यूज़र लिस्ट करने या रोल बदलने के प्रयास को ब्लॉक कर दे।
दृश्यता वह है जो इंटरफ़ेस दिखाना चुनता है। ऑथराइज़ेशन वह है जो सिस्टम वाकई सर्वर पर रिक्वेस्ट आ जाने पर अनुमति देगा।
अनुमतियों-सूचित मेनू कन्फ्यूज़न घटाते हैं। अगर कोई कभी Billing या Admin नहीं देख पाएगा, तो उन आइटम्स को छिपाने से ऐप साफ़ रहता है और सपोर्ट टिकट कम होते हैं। पर बटन छिपाना ताला नहीं है। लोग फिर भी देवटूल्स, पुराने बुकमार्क, या कॉपी किए गए रिक्वेस्ट से underlying endpoint आज़मा सकते हैं।
एक व्यवहारिक नियम: तय करें आप किस अनुभव की उम्मीद रखते हैं, और फिर UI जो भी करे, नियम को बैकएंड पर लागू करें।
जब आप किसी क्रिया को प्रस्तुत करने का निर्णय ले रहे हों, तीन पैटर्न अधिकतर मामलों को कवर करते हैं:
“आप देख सकते हैं पर संपादित नहीं कर सकते” आम है और इसे स्पष्ट रूप से डिज़ाइन करना चाहिए। इसे दो अनुमतियों की तरह व्यवहार करें: एक पढ़ने के लिए और एक बदलने के लिए। मेन्यू में, आप Customer details सभी पाठकों के लिए दिखा सकते हैं, पर Edit customer केवल उन्हीं के लिए दिखाएँ जिनके पास write एक्सेस है। पेज पर, फ़ील्ड्स को read-only रेंडर करें और एडिट कंट्रोल गेट करें, जबकि पेज लोड होने दें।
सबसे महत्वपूर्ण: बैकएंड अंतिम परिणाम तय करता है। भले ही UI हर एडमिन क्रिया को छिपा दे, सर्वर को हर संवेदनशील रिक्वेस्ट पर अनुमति जाँच करनी होगी और किसी ने भी प्रयास किया तो स्पष्ट “not allowed” प्रतिक्रिया देनी होगी।
सबसे तेज़ तरीका permission-aware मेन्यू शिप करने का यह है कि आप एक ऐसा मॉडल चुनें जिसे आपकी टीम एक वाक्य में समझा सके। यदि आप समझा नहीं सकते, तो आप इसे सही नहीं रख पाएंगे।
ग्रुपिंग के लिए रोल्स का उपयोग करें, अर्थ के लिए नहीं। Admin और Support उपयोगी बकेट हैं। पर जब रोल्स बढ़ने लगें (Admin-West-Coast-ReadOnly), UI भूलभुलैया बन जाती है और बैकएंड अनुमान लगाने लगता है।
कर्म के स्रोत-सत्य के रूप में परमिशन को प्राथमिकता दें। इन्हें छोटे और क्रिया-आधारित रखें, जैसे invoice.create या customer.export। यह role-sprawl से बेहतर स्केल करता है क्योंकि नई फिचर आमतौर पर नई क्रियाएँ जोड़ते हैं, नई नौकरी के शीर्षक नहीं।
फिर संदर्भ के लिए नीतियाँ (policies) जोड़ें। यहाँ आप हैंडल करते हैं “केवल अपना रिकॉर्ड एडिट कर सकता है” या “₹5,000 से कम के इनवॉइस ही अप्रूव कर सकता है।” नीतियाँ उन दर्जनों लगभग-डुप्लिकेट परमिशनों को बनने से रोकती हैं जो सिर्फ शर्तों से अलग होते हैं।
एक रख-रखाव योग्य लेयरिंग कुछ इस तरह दिखती है:
नामकरण अपेक्षा से ज़्यादा मायने रखता है। अगर आपकी UI कहती है Export Customers पर API उपयोग करता है download_all_clients_v2, तो आप अंततः गलत चीज़ छिपाएँगे या सही चीज़ ब्लॉक कर देंगे। नाम इंसान के अनुकूल, सुसंगत और फ्रंटेंड-बैकएंड दोनों में साझा रखें:
noun.verb (या resource.action) सुसंगत रूप से उपयोग करेंउदाहरण: एक CRM में, Sales रोल में lead.create और lead.update हो सकते हैं, पर एक नीति अपडेट को केवल यूज़र के अपने लीड्स तक सीमित कर सकती है। इससे मेन्यू साफ़ रहता है और बैकएंड सख्त रहता है।
अनुमतियों-सूचित मेन्यू अच्छा महसूस कराते हैं क्योंकि वे अव्यवस्था घटाते और आकस्मिक क्लिक रोकते हैं। पर वे तभी मदद करते हैं जब बैकएंड नियंत्रण में रहे। UI को संकेतक समझें, और सर्वर को न्यायाधीश।
शुरुआत में लिखें कि आप क्या सुरक्षा कर रहे हैं। पेज नहीं, बल्कि क्रियाएँ। View customer list अलग है export customers और delete customer से। यह ही backbone है ऐसे नेविगेशन मेन्यू का जो security theater में नहीं बदलते।
canEditCustomers, canDeleteCustomers, canExport जैसे बूलियन या अनुमति स्ट्रिंग्स की कॉम्पैक्ट लिस्ट लौटाएँ। इसे मिनिमल रखें।एक छोटा पर महत्वपूर्ण नियम: क्लाइंट-प्रदान किए गए role या permission फ्लैग पर कभी भरोसा न करें। UI capability के आधार पर बटन छिपा सकता है, पर API को अनधिकृत अनुरोधों को अभी भी अस्वीकार करना चाहिए।
परमिशन-सूचित नेविगेशन मेन्यू लोगों को यह ढूँढने में मदद करना चाहिए कि वे क्या कर सकते हैं, न कि यह दिखाना कि वे सुरक्षित हैं। फ्रंटेंड गाइडरेल है। बैकएंड ताला है।
हर बटन पर अलग-अलग परमिशन चेक बिखेरने की बजाय, अपनी नेविगेशन एक कॉन्फ़िग से परिभाषित करें जिसमें हर आइटम के लिए आवश्यक अनुमति हो, और फिर वहीं से रेंडर करें। इससे नियम पठनीय रहते हैं और UI के कोने-कोने में छूटे चेक्स की संभावना घटती है।
एक सरल पैटर्न इस तरह दिखता है:
const menu = [
{ label: "Contacts", path: "/contacts", requires: "contacts.read" },
{ label: "Export", action: "contacts.export", requires: "contacts.export" },
{ label: "Admin", path: "/admin", requires: "admin.access" },
];
const visibleMenu = menu.filter(item => userPerms.includes(item.requires));
पूरा सेक्शन (जैसे Admin) छिपाना प्रत्येक admin पेज लिंक पर चेक छिड़कने से बेहतर है। कम जगहों पर नियम रखेंगे तो गलती की संभावना कम होगी।
उन्हें छिपाएँ जब यूज़र के पास अनुमति न हो। डिसेबल करें जब यूज़र के पास अनुमति हो पर वर्तमान संदर्भ पर्याप्त नहीं हो।
उदाहरण: Delete contact तब तक डिसेबल होना चाहिए जब तक कोई contact चुना न गया हो। वही अनुमति है, बस संदर्भ नहीं है। डिसेबल करते समय नियंत्रक के पास एक छोटा “क्यों” संदेश जोड़ें (टूलटिप, हेल्पर टेक्स्ट या इनलाइन नोट): Select a contact to delete.
एक नियम सेट जो टिके रखता है:
मेन्यू आइटम छिपाने से लोग फोकस कर सकते हैं, पर यह कुछ भी सुरक्षित नहीं करता। बैकएंड अंतिम न्यायाधीश होना चाहिए क्योंकि रिक्वेस्ट को रीप्ले, एडिट या UI के बाहर ट्रिगर किया जा सकता है।
एक अच्छा नियम: हर ऐसी क्रिया जो डेटा बदलती है, उसे एक autorización चेक चाहिए, एक ही जगह पर, जिसे हर रिक्वेस्ट पास करे। यह मिडलवेयर, हैंडलर रैपर, या एक छोटा नीति लेयर हो सकता है जिसे आप हर एन्डपॉइंट के शुरूआत में कॉल करें। एक तरीका चुनें और उसी पर टिके रहें, वरना आप रास्तों को छोड़ देंगे।
ऑथराइज़ेशन को इनपुट वैलिडेशन से अलग रखें। पहले तय करें, “क्या यह यूज़र यह कर सकता है?”, फिर payload वैलिडेट करें। अगर पहले वैलिडेट करेंगे तो आप विवरण लीक कर सकते हैं (जैसे कौन सी रिकॉर्ड IDs मौजूद हैं) किसी को जो यह कार्रवाई संभव नहीं होनी चाहिए।
एक पैटर्न जो स्केल करता है:
Can(user, "invoice.delete", invoice)).ऐसे स्टेटस कोड उपयोग करें जो फ्रंटेंड और लॉग्स दोनों के लिए मददगार हों:
401 Unauthorized जब कॉलर लॉगिन नहीं है।403 Forbidden जब लॉगिन तो है पर अनुमति नहीं है।404 Not Found को एक छलावा के रूप में सावधानी से इस्तेमाल करें। यह किसी संसाधन का अस्तित्व छिपाने के लिए उपयोगी हो सकता है, पर यदि आप इसे बेतरतीब मिलाएंगे तो डिबगिंग मुश्किल हो जाएगी। हर संसाधन प्रकार के लिए एक सुसंगत नियम चुनें।
सुनिश्चित करें कि वही ऑथराइज़ेशन तब भी चले चाहे कार्रवाई बटन क्लिक से आई हो, मोबाइल ऐप से आई हो, स्क्रिप्ट से आई हो, या डायरेक्ट API कॉल से।
अंत में, डीनाइड प्रयासों को डिबगिंग और ऑडिट के लिए लॉग करें, पर लॉग्स को सुरक्षित रखें। रिकॉर्ड करें कौन, कौन सा एक्शन, और किस उच्च-स्तरीय संसाधन प्रकार पर। संवेदनशील फील्ड्स, पूरा payload या सीक्रेट्स लॉग में न रखें।
अधिकांश परमिशन बग उन मार्गों पर दिखते हैं जो आपका मेन्यू लेकर नहीं चलता। इसलिए permission-aware मेन्यू उपयोगी हैं, पर तभी जब आप उन पाथ्स के लिए भी डिज़ाइन करें जो उन्हें बाईपास कर देते हैं।
अगर मेन्यू किसी रोल के लिए Billing छिपाता है, तो यूज़र अभी भी सेव किया हुआ URL पेस्ट कर सकता है या ब्राउज़र हिस्ट्री से खोल सकता है। हर पेज लोड को ताजा रिक्वेस्ट की तरह ट्रीट करें: वर्तमान यूज़र की परमिशन फेच करें, और स्क्रीन खुद संरक्षित डेटा लोड होने से मना कर दे जब परमिशन गायब हो। एक दोस्ताना “आपको एक्सेस नहीं है” संदेश ठीक है, पर असली सुरक्षा यह है कि बैकएंड कुछ भी लौटाए ही नहीं।
कोई भी आपका API देवटूल्स, स्क्रिप्ट, या किसी अन्य क्लाइंट से कॉल कर सकता है। इसलिए हर एन्डपॉइंट पर चेक करें, सिर्फ़ एडमिन स्क्रीन पर नहीं। आसानी से छूट जाने वाला जोखिम बुलक एक्शन्स हैं: एक एकल /items/bulk-update बिना सावधानी के किसी नॉन-एडमिन को ऐसे फील्ड बदलने दे सकता है जो UI में नहीं दिखते।
रोल्स सत्र के बीच भी बदल सकते हैं। यदि एडमिन किसी अनुमति को हटा दे तो यूज़र के पास पुराना टोकन या कैश्ड मेन्यू स्टेट रह सकता है। शॉर्ट-लिव्ड टोकन या सर्वर-साइड परमिशन लुकअप का उपयोग करें, और 401/403 मिलने पर परमिशन रिफ्रेश और UI अपडेट करें।
शेयर्ड डिवाइसेज़ एक और जाल हैं: कैश्ड मेन्यू स्टेट खातों के बीच लीक कर सकता है। मेन्यू दृश्यता को यूज़र ID के साथ की-करकर सहेजें, या उसे बिल्कुल संरक्षित न रखें।
रिलीज़ से पहले पांच परीक्षण जो करने चाहिए:
कल्पना करें एक अंदरूनी CRM जहाँ तीन रोल्स हैं: Sales, Support, और Admin। हर कोई साइन इन करता है और ऐप बाएँ मेन्यू दिखाता है, पर मेन्यू सिर्फ सुविधा है। असली सुरक्षा सर्वर पर है—वो तय करता है क्या अनुमति है।
यहाँ एक सरल अनुमति सेट है जो पठनीय रहता है:
UI शुरू में बैकएंड से मौजूदा यूज़र की अनुमतियों की लिस्ट माँगती है (अक्सर अनुमति स्ट्रिंग्स की लिस्ट) और बेसिक संदर्भ जैसे user id और टीम। मेन्यू उसी से बनता है। अगर आपके पास billing.view नहीं है तो आप Billing नहीं देखते। अगर आपके पास leads.export है तो Leads स्क्रीन पर Export बटन दिखेगा। अगर आप केवल अपने लीड्स एडिट कर सकते हैं, तो Edit बटन तब भी दिखाई दे सकता है पर वह डिसेबल होना चाहिए या स्पष्ट संदेश दिखाना चाहिए जब लीड आपकी न हो।
अब महत्वपूर्ण हिस्सा: हर एक्शन एन्डपॉइंट वही नियम लागू करता है।
उदाहरण: Sales लीड बना सकता है और अपने-owned लीड्स को एडिट कर सकता है। Support टिकट देख सकता और असाइन कर सकता है पर बिलिंग छेड़छाड़ नहीं कर सकता। Admin यूज़र और बिलिंग मैनेज कर सकता है।
जब कोई लीड डिलीट करने की कोशिश करता है, तो बैकएंड चेक करता है:
leads.delete है?\n2) यदि नियम own-only है, तो क्या lead.owner_id == user.id?\n3) क्या लीड लॉक है (उदा., पहले ही इनवॉइस किया जा चुका है), तो क्या डिलीट सबके लिए ब्लॉक है सिवाय Admin के?यहां तक कि अगर Support यूज़र मैन्युअली delete एन्डपॉइंट को कॉल करे, उन्हें forbidden रिस्पॉन्स मिलेगा। छिपा हुआ मेन्यू सुरक्षा कभी नहीं था—बैकएंड निर्णय था।
सबसे बड़ा जाल यह सोच लेना है कि जब मेन्यू सही दिखे तो काम खत्म हो गया। बटन छिपाने से कन्फ्यूज़न घटती है, पर जोखिम नहीं घटता।
अक्सर दिखने वाली गलतियाँ:
isAdmin फ्लैग। यह तेज़ लगता है, फिर फैल जाता है। जल्दी ही हर अपवाद एक खास केस बन जाता है और कोई एक्सेस नियम समझ नहीं पाता।role, isAdmin, या permissions स्वीकार न करें। अपनी सेशन या टोकन से आइडेंटिटी निकाले और सर्वर-साइड रोल्स/परमिशन देखें।एक ठोस उदाहरण: आप non-managers के लिए Export leads मेन्यू आइटम छिपाते हैं। यदि एक्सपोर्ट एन्डपॉइंट में परमिशन चेक नहीं है, तो कोई भी यूज़र जो रिक्वेस्ट का अनुमान लगा ले या कॉपी कर ले, फाइल डाउनलोड कर सकता है।
अनुमतियों-सूचित मेन्यू शिप करने से पहले एक अंतिम पास करें जो इस बात पर केंद्रित हो कि यूज़र्स वास्तव में क्या कर सकते हैं, न कि वे क्या देख सकते हैं।
अपने ऐप को हर मुख्य रोल के रूप में चलाएँ और वही सेट ऑफ़ एक्शन्स आज़माएँ। UI में और सीधे एन्डपॉइंट को कॉल करके (या ब्राउज़र देवटूल्स से) सुनिश्चित करें कि सर्वर स्रोत-सत्य है।
चेकलिस्ट:
एक व्यावहारिक तरीका गैप्स पकड़ने का: एक “खतरनाक” बटन चुनें (यूज़र डिलीट करें, CSV एक्सपोर्ट, बिलिंग बदलें) और उसे एंड-टू-एंड ट्रेस करें। मेन्यू आइटम उचित समय पर छिपा होना चाहिए, API अनधिकृत कॉलों को अस्वीकार करे, और UI 403 मिलने पर सहजता से रिकवर करे।
छोटा शुरू करें। पहला दिन पर आपको परफ़ेक्ट एक्सेस मैट्रिक्स की ज़रूरत नहीं है। उन कुछ कार्रवाइयों को चुनें जो सबसे ज़्यादा मायने रखती हैं (view, create, edit, delete, export, manage users), उन्हें अपने मौजूदा रोल्स से मैप करें, और आगे बढ़ें। जब कोई नया फीचर आए, तो सिर्फ़ नई कार्रवाइयाँ जोड़ें जो वह लाता है।
स्क्रीन बनाने से पहले एक त्वरित प्लानिंग पास करें जो पेजों की बजाय क्रियाओं की लिस्ट दे। Invoices जैसा मेन्यू आइटम कई एक्शन्स छिपाता है: view list, view details, create, refund, export। पहले इन्हें लिखने से UI और बैकएंड नियम दोनों स्पष्ट होते हैं और आप यह गलती करने से बचते हैं कि पूरा पेज गेट किया जाए पर जोखिम भरा एन्डपॉइंट अन-प्रोटेक्टेड रह जाए।
जब आप एक्सेस नियम रिफैक्टर करें, इसे किसी अन्य जोखिम भरे बदलाव की तरह संभालें: एक सुरक्षा नेट रखें। स्नैपशॉट से आप व्यवहार पहले और बाद में तुलना कर सकते हैं। अगर किसी रोल से ज़रूरी एक्सेस अचानक चली जाती है, या अनचाही एक्सेस मिल जाती है, तो रोलबैक प्रोडक्शन में उपयोगकर्ताओं को ब्लॉक होने से तेज़ी से बेहतर है।
एक सरल रिलीज़ रूटीन टीमों को तेज़ी से आगे बढ़ने में मदद करता है बिना अनुमान लगाए:
यदि आप चैट-आधारित प्लेटफ़ॉर्म जैसे Koder.ai (koder.ai) के साथ बना रहे हैं, तो वही संरचना लागू होती है: परमिशन और नीतियाँ एक बार परिभाषित रखें, UI सर्वर से capabilities पढ़े, और हर हैंडलर में बैकएंड चेक अनिवार्य बनाएं।
अनुमतियों-सूचित मेन्यू ज्यादातर स्पष्टता हल करते हैं, सुरक्षा नहीं। ये यूज़र्स को वही दिखाते हैं जो वे कर सकते हैं, डेड-एंड क्लिक घटाते हैं, और “मुझे यह क्यों दिख रहा है?” जैसे सपोर्ट सवाल कम करते हैं。
सुरक्षा हमेशा बैकएंड पर लागू करनी चाहिए, क्योंकि कोई भी डीप लिंक, पुराना बुकमार्क, या डायरेक्ट API कॉल कर सकता है—UI जो दिखाता है वह अंतिम फैसला नहीं है।
छिपाएँ जब कोई फीचर किसी रोल के लिए मूल रूप से अप्रकटनीय होना चाहिए।
अक्षम (disable) करें जब यूज़र के पास फ़ीचर हो सकता है लेकिन अभी संदर्भ नहीं है—जैसे कोई रिकॉर्ड चुना नहीं गया है, फॉर्म वैध नहीं है, या डेटा लोड हो रहा है। यदि आप डिसेबल करते हैं तो पास में एक छोटा कारण दिखाएँ ताकि चीज़ टूटी-फूटी न लगे।
क्योंकि दिखाई देना ऑथराइज़ेशन नहीं है। एक यूज़र URL पेस्ट कर सकता है, बुकमार्केड एडमिन स्क्रीन दोहरा सकता है, या UI के बाहर API कॉल कर सकता है。
UI को मार्गदर्शक मानें। हर संवेदनशील रिक्वेस्ट का अंतिम निर्णय बैकएंड करे।
सर्वर लॉगिन या सेशन रिफ्रेश के बाद एक छोटा “capabilities” रिस्पॉन्स लौटाए जो सर्वर-साइड परमिशन चेक्स पर आधारित हो। UI फिर उसी के आधार पर मेन्यू और बटन रेंडर करे。
ब्राउज़र से आने वाले isAdmin जैसे क्लाइंट-प्रदत्त फ़्लैग पर भरोसा न करें; परमिशन ऑथेंटिकेटेड आइडेंटिटी से सर्वर पर ही निकालें।
एक्शन की सूची से शुरू करें, पेजों से नहीं। हर फीचर के लिए read, create, update, delete, export, invite, billing-changes जैसी अलग-अलग क्रियाएँ लिखें।
फिर हर एक्शन को बैकएंड हैंडलर (या मिडलवेयर/रैपर) में लागू करें—उसके बाद UI को वही परमिशन नाम दिखाएँ जिससे दोनों जुड़े रहें।
व्यवहारिक डिफ़ॉल्ट: रोल्स समूह हैं, परमिशन स्रोत-सत्य। परमिशन को छोटा और क्रिया-आधारित रखें (उदा., invoice.create) और उन्हें रोल्स में लगाएँ।
अगर रोल्स ऐसी शर्तें एन्कोड करने लगें (जैसे क्षेत्र या ओनरशिप), तो उन शर्तों को नीतियों में डालें बजाय अनगिनत रोल बनाने के।
कॉन्टेक्स्चुअल नियमों के लिए नीतियों का उपयोग करें—जैसे “केवल अपना रिकॉर्ड एडिट कर सकता है” या “₹5,000 से कम के इनवॉइस ही अप्रूव कर सकता है।” इससे आपकी परमिशन सूची स्थिर रहती है पर वास्तविक-विश्व शर्तें व्यक्त होती हैं।
बैकएंड को नीति का इलाज संसाधन संदर्भ (owner ID, org ID) के साथ करना चाहिए, UI के अनुमानों के आधार पर नहीं।
हमेशा नहीं। संवेदनशील रीड्स या वे जो सामान्य फ़िल्टरिंग को बायपास करते हैं—जैसे एक्सपोर्ट, ऑडिट लॉग, सैलेरी डेटा, एडमिन यूज़र लिस्ट—उन्हें भी गेट करना चाहिए।
एक अच्छा बेसलाइन: सभी राइट्स चेक करें, और संवेदनशील रीड्स भी चेक करें।
बुलक एंडपॉइंट्स जल्दी छूट जाते हैं क्योंकि वे एक अनुरोध में कई रिकॉर्ड या फील्ड बदल सकते हैं। हमेशा उस बुलक क्रिया की परमिशन चेक करें, और यह भी सत्यापित करें कि किसी रोल के लिए कौन से फील्ड बदले जा सकते हैं—वरना आप छिपे हुए फील्ड संपादित होने दे सकते हैं।
समझें कि परमिशन किसी भी समय बदल सकती हैं। जब API 401 या 403 लौटाए, UI को इसे सामान्य स्थिति के रूप में संभालना चाहिए: capabilities रिफ्रेश करें, मेन्यू अपडेट करें, और स्पष्ट संदेश दिखाएँ।
साझा डिवाइस पर मेन्यू स्टेट को ऐसे सुरक्षित रखें कि वह खातों के बीच लीक न हो; यदि आप कैश करें तो उसे यूज़र आइडेंटिटी के साथ की-करें या बिल्कुल न सहेजें।