एक्सेस निर्णय कैसे काम करते हैं

यह पेज हर अनलॉक के पीछे के मॉडल को समझाता है: किसे दरवाज़े से गुज़रने की अनुमति है, जाँचें किस क्रम में चलती हैं, और Access Policies, अनुदान और सुरक्षा जाँचें आपस में कैसे काम करती हैं। इसे पहले पढ़ें — बाकी हर पेज इन्हीं अवधारणाओं पर आधारित है।

जुड़ते जाने वाले अनुमति के रास्ते

किसी उपयोगकर्ता को किसी भी पॉलिसी या अनुदान रास्ते से दरवाज़े से गुज़रने की अनुमति मिल सकती है। एक रास्ता पास करना पर्याप्त है; एक रास्ता कभी भी दूसरे रास्ते से मिली पहुँच को घटाता नहीं है।

कोई पॉलिसी तभी मेल खाती है जब Who AND Where AND When मेल खाते हैं। पॉलिसी आपस में OR से जुड़ती हैं। Who के भीतर, व्यक्ति-प्रकार/स्थिति शर्तें और टैग विकल्प हैं; When के भीतर, Weekly और One-time विंडो विकल्प हैं। Where में सुविधा के सभी दरवाज़े, Access Scopes, अलग-अलग दरवाज़े और अपवर्जन शामिल हो सकते हैं।

उदाहरण: एक "Active members" पॉलिसी Front entrances स्कोप को Anytime कवर कर सकती है, जबकि एक अलग "Staff" पॉलिसी Plant room को छोड़कर सुविधा के सभी दरवाज़ों को कवर करती है। कोई सफ़ाईकर्मी जो दोनों में से किसी से मेल नहीं खाता, उसे फिर भी Service entries स्कोप के लिए स्थायी अनुदान मिल सकता है।

स्थायी अनुदान और एडमिनिस्ट्रेटर/इंटीग्रेशन विंडो अलग और जुड़ते जाने वाले रहते हैं। पॉलिसी संपादन और स्वचालित आयात उन्हें न तो समाहित करते हैं और न ही हटाते हैं।

Users में सिंक किए गए Performance Hub स्टाफ़ को किसी भी अन्य पॉलिसी की तरह संपादन योग्य Performance Hub staff पॉलिसी के माध्यम से दरवाज़ा पहुँच मिलती है। देखें सिंक और इंटीग्रेशन।

पूरा निर्णय क्रम

जब कोई उपयोगकर्ता मोबाइल ऐप में Unlock पर टैप करता है, तो सर्वर क्रम से निम्नलिखित की जाँच करता है। पहली विफल जाँच अनलॉक को अस्वीकार कर देती है और कारण को एक्सेस लॉग में दर्ज करती है।

1. क्या उपयोगकर्ता की पहुँच सक्षम है? Users में उपयोगकर्ता की पंक्ति पर Access enabled स्विच एक एडमिन किल स्विच है। हटाए गए, अक्षम या सिंक-ब्लॉक किए गए उपयोगकर्ता पॉलिसी या अनुदान की परवाह किए बिना अनलॉक नहीं कर सकते। (उदाहरण के लिए: access_disabled।)
2. क्या दरवाज़ा ब्लॉक है या रखरखाव में है? स्पष्ट blockAllAccess सदस्य के हर रास्ते को अस्वीकार करता है। रखरखाव Force closed दरवाज़े को लॉक और सदस्यों के लिए सेवा से बाहर रखता है; Force open दरवाज़े को अनलॉक रखता है। एडमिन किसी दरवाज़े को दूर से अनलॉक कर सकते हैं; हर एडमिन अनलॉक एक्सेस लॉग में दर्ज होता है।
3. क्या कोई जुड़ता हुआ अनुमति रास्ता पास होता है?
   • पॉलिसी रास्ता: कोई भी सक्षम नामित पॉलिसी जिसके Who, Where और When सभी मेल खाते हैं, पहुँच की अनुमति देती है।
   • स्थायी-अनुदान रास्ता: सुविधा, दरवाज़े या उसे शामिल करने वाले Access Scope का अनुदान तब पहुँच देता है जब उसके वैकल्पिक घंटे मेल खाते हैं।
   • उपयोगकर्ता विंडो रास्ता: एडमिनिस्ट्रेटर के स्वामित्व वाली कोई Access Time Window सक्रिय है और इस दरवाज़े, सुविधा, या इसे शामिल करने वाले Access Scope को लक्षित करती है।
   • इंटीग्रेशन विंडो रास्ता: कोई ताज़ा स्रोत विंडो सक्रिय है और उसकी कॉन्फ़िगर की गई scope_key मैपिंग इस दरवाज़े को लक्षित करती है। पुरानी या बिना मैप की गई स्रोत विंडो बंद अवस्था में विफल होती हैं।
   • यदि कोई भी पास नहीं होता → अस्वीकृत (no_matching_policy_or_grant)
4. जियोफ़ेंस जाँच (यदि सक्षम हो)। फ़ोन द्वारा रिपोर्ट किए गए स्थान का उपयोग करके:
   • यदि फ़ोन स्थान नहीं दे सका → अस्वीकृत (location_unavailable)
   • यदि GPS रीडिंग Require GPS accuracy better than सेटिंग से कम सटीक है → अस्वीकृत (gps_too_imprecise)
   • यदि जियोफ़ेंस केंद्र से उपयोगकर्ता की दूरी त्रिज्या + GPS सटीकता + सटीकता बफ़र से अधिक है → अस्वीकृत (outside_geofence)
   • सर्वर ही अंतिम निर्णायक है — फ़ोन पर नकली स्थान फिर भी सर्वर-साइड पर अस्वीकार कर दिया जाता है।
5. क्या डोर कंट्रोलर ऑनलाइन है? यदि कंट्रोलर ने रिपोर्ट नहीं किया है (पिछले 5 मिनट के भीतर हार्टबीट), तो अनलॉक पहुँचाया नहीं जा सकता (device_offline)। यदि कमांड भेजा जाता है लेकिन कंट्रोलर पुष्टि नहीं करता, तो इवेंट Timed out के रूप में दर्ज होता है।
6. अनलॉक। रिले दरवाज़े के Hold time (1–30 सेकंड, डिफ़ॉल्ट 10) के लिए रिलीज़ होता है, फिर स्वचालित रूप से फिर से लॉक हो जाता है। कंट्रोलर के पुष्टि करने पर इवेंट Confirmed unlocked के रूप में दर्ज होता है।

One-time और सीमित Weekly विंडो पूर्णांक Unix-सेकंड सीमाओं और अर्ध-खुली सीमाओं [from, to) का उपयोग करती हैं: प्रारंभ योग्य होता है और अंत नहीं। Weekly ब्लॉक अपने घोषित IANA टाइमज़ोन और स्थानीय घड़ी/DST नियमों का उपयोग करते हैं। देखें Access Policy Schedules।

नए क्लाइंट को केवल भविष्य की विंडो वाले दरवाज़े के लिए outside_access_time_window विवरण के साथ संरचित अगली उपलब्धता मिलती है। संगतता रोलआउट के दौरान, पुराने क्लाइंट को प्राथमिक कारण के रूप में outside_access_hours मिलता रहता है, ताकि दरवाज़ा सुरक्षित रूप से अक्षम और दृश्यमान बना रहे।

मौजूदा कॉन्फ़िगरेशन

मौजूदा एक्सेस कॉन्फ़िगरेशन स्वचालित रूप से Access Policies में आयात किया जाता है। आयात यह सुरक्षित रखता है कि किसके पास पहुँच थी, वे किन दरवाज़ों या Access Scopes का उपयोग कर सकते थे, और लागू घंटे, पॉलिसी के Who, Where और When मानों के रूप में। एडमिनिस्ट्रेटर परिणामी पॉलिसी को सीधे प्रबंधित करते हैं; कोई रोलआउट मोड या मैन्युअल रूपांतरण वर्कफ़्लो नहीं है।

जियोफ़ेंस इनहेरिटेंस Access Policies से स्वतंत्र रहता है। पॉलिसी मेल खाने पर भी प्रभावी जियोफ़ेंस और अन्य सभी सुरक्षा/डिवाइस जाँचों से गुज़रना होता है।

OTP साइन-इन क्या करता है और क्या नहीं करता

मोबाइल ऐप में साइन इन करना (SMS या ईमेल से वन-टाइम कोड) केवल प्रमाणीकरण है — यह साबित करता है कि उपयोगकर्ता कौन है। यह अपने आप दरवाज़ा पहुँच नहीं देता। हर अनलॉक ऊपर दिए गए निर्णय क्रम का उपयोग करके अलग से अधिकृत किया जाता है। कोई उपयोगकर्ता ऐप में साइन इन होते हुए भी "You don't have access to this door." देख सकता है।

शब्दावली

संबंधित पेज

• Access Policies — Who, Where, When और स्वचालित आयात
• Access Policy Schedules — Anytime, Weekly और One-time
• Access Scopes — पुन: उपयोग योग्य दरवाज़ा समूह
• Geofencing — स्थान जाँच
• Users — प्रति-उपयोगकर्ता अनुदान और किल स्विच
• संदर्भ — हर अस्वीकृति कारण और डिफ़ॉल्ट एक ही तालिका में
• दरवाज़ों को Duress प्रतिक्रियाओं में भी शामिल किया जा सकता है। Duress में प्रतिक्रिया कार्रवाइयाँ देखें।