डेिगेटेड एक्सेस

लोगों को केवल वही एक्सेस दें जिसकी उन्हें आवश्यकता है — और कुछ नहीं

एक डेवलपर को शामिल करें, अपने अकाउंटेंट को बिलिंग सौंपें, किसी क्लाइंट को उनकी अपनी साइटों पर रीड-ऑनली एक्सेस दें, या हमारी सहायता टीम को किसी समस्या की जाँच करने दें। हर अनुमति तयशुदा अधिकारों वाली एक भूमिका है, जो किसी संगठन तक सीमित है, डेटाबेस में लागू की जाती है, और केवल-अपेंड (append-only) ऑडिट लॉग में लिखी जाती है।

  • 94विस्तृत अनुमतियाँ
  • 12बिल्ट-इन भूमिकाएँ
  • 8स्टाफ विभाग
  • 650,000+दुनिया भर में होस्ट की गई साइटें

एक्सेस एक सदस्यता है, साझा पासवर्ड नहीं

एक ही लॉगिन साझा करना खाता पहुँच को संकट में डालता है। Zinn Digital® पर हर व्यक्ति की अपनी पहचान होती है, और पहुँच एक सदस्यता है — एक उपयोगकर्ता, एक संगठन, और एक भूमिका — जिसे आप अपने दम पर दे सकते हैं, बदल सकते हैं या रद्द कर सकते हैं।

आपकी अपनी पहचान, हमेशा

हर सहयोगी Keycloak, जो हमारी पहचान परत है, के माध्यम से स्वयं के रूप में साइन इन करता है। कोई भी आपका पासवर्ड टाइप नहीं करता है, कोई भी ब्राउज़र सत्र साझा नहीं करता है, और किसी को हटाना पासवर्ड बदलने और यह पता लगाने की भगदड़ के बजाय एक ही कार्रवाई है कि और कौन इसे जानता था।

संगठन एक ट्री बनाते हैं

खाते पदानुक्रमित होते हैं — एक पुनर्विक्रेता संगठन के पास ग्राहक संगठन होते हैं, और ग्राहक संगठन के पास साइटें होती हैं। एक सदस्यता किसी संगठन और उसके अंतर्गत आने वाली हर चीज़ पर लागू होती है, इसलिए आप अपने अन्य ग्राहकों को कभी भी उजागर किए बिना किसी एजेंसी ग्राहक को उनके अपने संगठन का नियंत्रण सौंप सकते हैं।

डेटाबेस में आइसोलेशन लागू किया गया है

टेनेंट सेपरेशन (Tenant separation) एप्लीकेशन कोड में कोई ऐसा फ़िल्टर नहीं है जिसे कोई बग छोड़ सके। पोस्टग्रेज रो-लेवल सिक्योरिटी (Postgres Row-Level Security) हर क्वेरी को कॉलर के ऑर्गनाइजेशन सबट्री तक सीमित करती है, इसलिए आपके दायरे से बाहर के अनुरोध के लिए कुछ भी वापस करने को नहीं होता।

अनुपस्थिति अदृश्य है

अपनी पहुँच से बाहर किसी संगठन या साइट के बारे में पूछने पर API अनुमति त्रुटि के बजाय केवल एक 'नहीं मिला' (not-found) उत्तर देता है। एक अनुमति त्रुटि से यह पुष्टि हो जाएगी कि रिकॉर्ड मौजूद है; 'नहीं मिला' संदेश बाहर के व्यक्ति को कुछ भी नहीं बताता है।

चार ग्राहक भूमिकाएं, पैंतीस अनुमतियाँ

अनुमतियाँ दानेदार कुंजियाँ हैं — मॉड्यूल और क्रिया, जैसे sites.restart या billing.refund — और भूमिकाएँ उन्हें बंडल करती हैं। चार भूमिकाएँ वास्तविक टीमों की ज़रूरतों को पूरा करती हैं, और प्रत्येक डेटा है जिसे हम सीड करते हैं, न कि कोड में छिपी हुई तर्क।

मालिक

पूर्ण नियंत्रण: सब-ऑर्गनाइजेशन बनाएं, सदस्यों को आमंत्रित करें और हटाएं, भूमिकाएं बदलें, API कुंजियां प्रबंधित करें, साइटें बनाएं, रीस्टार्ट करें, पर्ज करें, निलंबित करें और हटाएं, बिलिंग और चालान चलाएं, टिकट उठाएं और ऑडिट लॉग पढ़ें। वह भूमिका जो आप अपने लिए रखते हैं।

बिलिंग प्रबंधक

संगठन, उसके सदस्यों और योजना कैटलॉग को देखता है, और चालान, भुगतान विधियों और शुल्कों का प्रबंधन करता है। किसी एकल साइट को बनाने, बदलने या हटाने की कोई पहुँच नहीं है — बिल्कुल वैसी ही भूमिका जैसी किसी बाहरी बहीखाताकार की होनी चाहिए।

डेवलपर

साइट्स को देखता और बनाता है, सेवाओं को रीस्टार्ट करता है, कैश साफ़ करता है, API कुंजियों का प्रबंधन करता है और टिकटों पर काम करता है। जानबूझकर बाहर रखा गया है: बिलिंग, चालान, भुगतान विधियाँ, सदस्य प्रबंधन, साइट निलंबन और साइट हटाना। एक ठेकेदार आपको बिल भेजे बिना या कुछ भी नष्ट किए बिना निर्माण कर सकता है।

केवल-पठन

संगठन, उसके सदस्यों, उसकी साइटों, उसकी बिलिंग, प्लान कैटलॉग, टिकटों, अनुवाद स्थिति और ऑडिट लॉग को देखता है — और उनमें से किसी को भी बदल नहीं सकता। यह अधिकार उस क्लाइंट के लिए है जिसे विजिबिलिटी चाहिए, किसी ऑडिटर के लिए, या ऐसे हितधारक (स्टेकहोल्डर) के लिए जिसे केवल देखने की आवश्यकता है।

आपकी टीम चुपचाप कमज़ोर नहीं पड़ सकती

पहुँच सौंपना तभी सुरक्षित है जब जिन खातों को आप पहुँच सौंप रहे हैं, उन पर कब्जा करना कठिन हो। खाते के प्रत्येक व्यक्ति के लिए, हर सतह पर, प्रमाणीकरण Keycloak के माध्यम से चलता है।

  • फ़िशिंग-प्रतिरोधी साइन-इन के लिए पासकीज़ और WebAuthn, साथ ही नीति द्वारा सभी के लिए अनिवार्य TOTP टू-फैक्टर ऑथेंटिकेशन - कोई वैकल्पिक सेटिंग नहीं जिसे टीम का कोई सदस्य छोड़ सके।
  • डिफ़ॉल्ट के रूप में मैजिक-लिंक ईमेल साइन-इन, ईमेल और पासवर्ड के साथ फ़ॉलबैक के रूप में, और Google, Microsoft, GitHub तथा अन्य के माध्यम से सोशल साइन-इन।
  • एंटरप्राइज़ और एजेंसी ग्राहकों के लिए SAML सिंगल साइन-ऑन, ताकि नए और जाने वाले कर्मचारियों को हाथ से प्रबंधित करने के बजाय आपके पहचान प्रदाता (identity provider) द्वारा संभाला जा सके।
  • कस्टमर डैशबोर्ड, पब्लिक साइट, नॉलेज बेस और सपोर्ट टिकटों में एक ही सत्र — एक बार साइन इन करें, और एक बार में निरस्त करें।
  • सत्र नीतियाँ, संवेदनशील क्रियाओं पर स्टेप-अप प्रमाणीकरण, और ज्ञात नेटवर्क से एक्सेस सीमित रखने वाले खातों के लिए वैकल्पिक प्रति-संगठन आईपी अनुमति सूचियाँ।
  • खाता बनने से पहले हर साइन-अप ईमेल को सत्यापित किया जाता है, ताकि बाउंस होने वाले, डिस्पोजेबल और रोल पते शुरुआत में ही रोक लिए जाएं, न कि बाद में कोई लावारिस सदस्य बनें।

जब हमारी टीम को एक्सेस की आवश्यकता होती है, तो यह सीमित और लॉग किया जाता है

सपोर्ट के काम में कभी-कभी आपके अकाउंट के भीतर देखना पड़ता है। उस एक्सेस को बाकी सभी चीज़ों की तरह ही अनुमति मॉडल द्वारा नियंत्रित किया जाता है — कर्मचारी बस एक कर्मचारी संगठन में बैठते हैं, जो सीमित अनुदानों वाले विभागों में व्यवस्थित होते हैं।

विभाग, न कि संपूर्ण व्यवस्थापक

कर्मचारियों को सहायता (सपोर्ट), बिलिंग और वित्त, एब्यूज और ट्रस्ट-एंड-सेफ्टी, बिक्री (सेल्स), ऑनबोर्डिंग, इंजीनियरिंग और ऑप्स, मार्केटिंग और प्रबंधन में समूहीकृत किया गया है। प्रत्येक भूमिका विशिष्ट मॉड्यूल और क्रियाएं प्रदान करती है, ताकि एजेंट को एडमिन कंसोल का केवल वही हिस्सा दिखाई दे जिसकी उसके काम को आवश्यकता है, बाकी नहीं।

एक सहायता एजेंट की वास्तविक सीमा

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

एक ग्राहक के रूप में साइन इन करना कड़ाई से सुरक्षित रखा गया है

customer.impersonate अनुमति मैनेजर भूमिका का हिस्सा नहीं है — यह केवल सुपर एडमिन के पास होती है। जब आपकी ओर से कोई सत्र चल रहा होता है, तो डैशबोर्ड पर एक स्थायी प्रतिरूपण बैनर होता है ताकि यह कभी भी संदिग्ध न हो कि कौन कार्रवाई कर रहा है।

हर विशेषाधिकार प्राप्त चीज़ लिखी जाती है

प्रत्येक विशिषाधिकार प्राप्त और प्रशासनिक कार्रवाई केवल-जोड़ने योग्य (append-only) ऑडिट लॉग में जोड़ी जाती है, जो अभिनेता, कार्रवाई, लक्ष्य, सहायक मेटाडेटा, आईपी पते और टाइमस्टैम्प को रिकॉर्ड करती है — उत्पादन (production) में समय-विभाजित (time-partitioned)। मालिक और केवल-पढ़ने वाले सदस्य अपने संगठन के लॉग को स्वयं पढ़ सकते हैं।

विनाशकारी कार्य पर अनुमोदन द्वार

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

मशीनों को भी प्रतिनिधि पहुँच मिलती है

स्क्रिप्ट्स, CI पाइपलाइन्स, CLI, टेराफॉर्म प्रदाता और AI एजेंट सभी लोगों की तरह ही समान अनुमति मॉडल के माध्यम से प्रमाणित करते हैं — कोई साझा मानवीय क्रेडेंशियल नहीं, न ही किसी बिल्ड में पेस्ट किए गए लंबे समय तक रहने वाले सीक्रेट्स।

API कुंजियाँ संगठन-वार और स्कोप वाली होती हैं

कुंजियाँ एक संगठन से संबंधित होती हैं और समान RBAC अनुमतियों से जुड़ी दानेदार अनुमतियों को वहन करती हैं — केवल-पढ़ने के लिए (read-only), बिलिंग, प्रोविजनिंग। किसी सदस्य के पूरे खाते के बजाय किसी पाइपलाइन को वह सीमित अनुमति दें जिसकी उसे आवश्यकता है।

सैंडबॉक्स कुंजियाँ प्रोडक्शन से अलग हैं

टेस्ट-मोड और लाइव-मोड कुंजियाँ अलग-अलग होती हैं, इसलिए विकास के अधीन कोई इंटीग्रेशन गलती से या कॉपी किए गए एनवायरनमेंट वेरिएबल के कारण प्रोडक्शन डेटा तक नहीं पहुँच सकता।

केवल हैश ही संग्रहीत किया जाता है

हम गुप्त कुंजी (secret) का SHA-256 हैश और एक लुकअप उपसर्ग (lookup prefix) संग्रहीत करते हैं—मूल कुंजी को कभी नहीं। आपको निर्माण के समय कुंजी केवल एक बार दिखाई देती है। प्रत्येक कुंजी यह ट्रैक करती है कि उसका उपयोग अंतिम बार कब किया गया था और बिना किसी अन्य चीज़ को प्रभावित किए इसे स्वतंत्र रूप से निरस्त (revoked) किया जा सकता है।

एआई टूल्स आपकी अनुमति से कनेक्ट होते हैं

हमारा MCP सर्वर किसी भी MCP-सक्षम एजेंट को आपकी होस्टिंग को प्राकृतिक भाषा में प्रबंधित करने की अनुमति देता है, जो OAuth 2.1 से प्रमाणित और आपके संगठन व RBAC भूमिका तक सीमित है, जिसमें प्रति-टूल निरस्त करने योग्य टोकन, विनाशात्मक क्रियाओं पर पुष्टिकरण, खर्च की सीमाएं और पूर्ण ऑडिट लॉगिंग शामिल हैं।

साइट्स तक पहुंच

अकाउंट एक्सेस और सर्वर एक्सेस अलग-अलग समस्याएं हैं। साइट-स्तरीय क्रेडेंशियल्स डैशबोर्ड में प्रबंधित किए जाते हैं, न्यूनतम-विशेषाधिकार के साथ जारी किए जाते हैं, और जेल किए जाते हैं ताकि एक सहयोगी की शेल एक साइट की शेल हो।

  • जेल्ड शेल के साथ SSH, साथ ही SFTP और FTP — CageFS आइसोलेशन का मतलब है कि प्रत्येक टेनेंट को केवल अपनी फ़ाइलें दिखाई देती हैं।
  • पैनल टर्मिनल से और SSH पर wp-cli, उन ऑपरेशन्स के लिए जिन्हें डेवलपर्स वास्तव में स्क्रिप्ट करना चाहते हैं।
  • code-server के माध्यम से ब्राउज़र में एक पूर्ण VS Code एडिटर — एक्सटेंशन, इंटीग्रेटेड टर्मिनल और गिट, डैशबोर्ड में सीधे साइट की फ़ाइलों को संपादित करना।
  • डेटाबेस के लिए एम्बेडेड phpMyAdmin और Adminer और एक एम्बेडेड फ़ाइल मैनेजर, दोनों डैशबोर्ड से सिंगल-साइन-ऑन के साथ उपलब्ध हैं, न कि क्रेडेंशियल्स के दूसरे सेट के पीछे सुरक्षित।
  • डैशबोर्ड में एक्सेस कुंजियाँ और क्रेडेंशियल बनाए, सूचीबद्ध, घुमाए और निरस्त किए जाते हैं, न्यूनतम-विशेषाधिकार पर जारी किए जाते हैं, और उनके उपयोग का ऑडिट-लॉग रखा जाता है।
  • क्लोन और पुश-टू-लाइव (push-to-live) के साथ स्टेजिंग, जोखिम भरे काम को प्रोडक्शन से दूर रखती है, ताकि किसी नए सहयोगी का पहला बदलाव सीधे लाइव साइट पर कभी न जाए।

जिस तरह से आप वास्तव में काम करते हैं, उसके लिए एक्सेस को कैसे संरचित करें

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

एक एजेंसी संगठन वृक्ष का उपयोग करती है। प्रत्येक क्लाइंट को अपनी खुद की चाइल्ड ऑर्गेनाइजेशन मिलती है, जिसमें उस क्लाइंट की साइटें होती हैं, और क्लाइंट के अपने लोगों को वहाँ सदस्यताएँ मिलती हैं - दृश्यता चाहने वाले स्टेकहोल्डर के लिए रीड-ऑनलाइन, और खुद से सेवा चाहने वाले क्लाइंट के लिए ओनर। आपके स्टाफ के पास वृक्ष में ऊपर की ओर सदस्यताएँ होती हैं और वे पोर्टफोलियो देखते हैं; एक क्लाइंट केवल अपनी खुद की शाखा देखता है, और रो-लेवल सिक्योरिटी (पंक्ति-स्तर सुरक्षा) इसे एक वादा बनाने के बजाय सच साबित करती है।

एक रीसेलर ठीक उसी तरह काम करता है, बस एक स्तर ऊपर: एक रीसेलर संगठन के अंतर्गत क्लाइंट संगठन होते हैं, जिनमें से प्रत्येक के अपने सदस्य, बिलिंग दृश्य और साइट्स होते हैं। वही बुनियादी ढांचा सब-अकाउंट्स, एजेंसी टीमों और रीसेलर पदानुक्रमों को शक्ति प्रदान करता है — उनमें से किसी के लिए भी कोई अलग या कमजोर तंत्र नहीं है।

कार्ड-मुक्त 14-दिन के परीक्षण पर सब कुछ उपलब्ध है। भुगतान विवरण के बिना साइन अप करें, किसी सहकर्मी को आमंत्रित करें, देखें कि प्रत्येक भूमिका क्या एक्सेस कर सकती है और क्या नहीं, और अपना खुद का ऑडिट लॉग वापस पढ़ें।

अक्सर पूछे जाने वाले प्रश्न

क्या मैं किसी को केवल एक साइट का एक्सेस दे सकता हूँ?

आज एक सदस्यता पूरे संगठन में और उसके अंतर्गत आने वाले सभी स्तरों पर अपनी भूमिका प्रदान करती है, इसलिए साइट सेट को अलग करने का तरीका यह है कि संगठनों को अलग किया जाए - उन साइटों को उनके अपने चाइल्ड संगठन में रखें और वहां सदस्यता प्रदान करें। यह एजेंसियों और पुनर्विक्रेताओं के लिए एक स्पष्ट मॉडल है, जहाँ प्रत्येक ग्राहक पहले से ही अपनी खुद की सीमा चाहता है। प्रति-सदस्यता संसाधन सीमित करना, यानी एक संगठन के भीतर नामित साइटों से एक ही सदस्यता को जोड़ना, वर्तमान में उपलब्ध होने के बजाय भविष्य की एक नियोजित सुधार प्रक्रिया है।

क्या मेरे द्वारा आमंत्रित किया गया कोई डेवलपर किसी साइट को हटा सकता है या लाइव पर पुश कर सकता है?

डेवलपर भूमिका में साइट हटाने या साइट को निलंबित करने की अनुमति नहीं होती है — वे अधिकार स्वामी (Owner) की भूमिका के पास होते हैं। यह साइट देखने और बनाने, सेवाओं को पुनरारंभ करने, कैश साफ़ करने, API कुंजियों का प्रबंधन करने और टिकटों पर काम करने की अनुमति देता है। परिनियोजन (Deployment) और लाइव-पुश अनुमतियां भी डेवलपर अनुमति का हिस्सा नहीं हैं, इसलिए प्रोडक्शन में प्रमोशन खाता स्वामी के पास ही रहता है। इसे स्टेजिंग के साथ जोड़ें ताकि बिल्ड का काम सबसे पहले लाइव साइट से बाहर हो सके।

Zinn Digital® स्टाफ मेरे खाते में क्या देख सकता है?

यह पूरी तरह से स्टाफ की भूमिका पर निर्भर करता है, और प्रत्येक भूमिका अनुमति कुंजियों का एक सीमित सेट होती है। उदाहरण के लिए, एक सपोर्ट एजेंट आपके खाते और साइटों को देख सकता है, आपके टिकट देख सकता है और उनका जवाब दे सकता है, किसी साइट को पुनः आरंभ कर सकता है और उसके कैश को साफ़ कर सकता है — और वह बिलिंग कॉन्फ़िगरेशन, रिफ़ंड, प्लान या फ्लीट को नहीं छू सकता है। एक ग्राहक के रूप में साइन इन करना एक अलग अनुमति है जो केवल सुपर एडमिन के पास होती है, और जब ऐसा होता है तो डैशबोर्ड पर एक स्थायी इंपर्सनेशन बैनर दिखाई देता है। हर विशेषाधिकार प्राप्त कार्रवाई को ऑडिट लॉग में अभिनेता, कार्रवाई, लक्ष्य, आईपी और टाइमस्टैम्प के साथ दर्ज किया जाता है, और आप अपने संगठन के लॉग को स्वयं पढ़ सकते हैं।

अगर कोई कर्मचारी चला जाए, तो मैं तुरंत एक्सेस कैसे रद्द करूँ?

सदस्यता हटाएँ और उस संगठन तक उनकी पहुँच समाप्त हो जाती है — उनके पास अभी भी उनकी अपनी पहचान है, लेकिन कोई भूमिका नहीं है और इसलिए आपके खाते में कोई अनुमति नहीं है। API कुंजियाँ व्यक्तिगत रूप से निरस्त की जाती हैं, इसलिए किसी अन्य चीज़ को बाधित किए बिना एक पाइपलाइन कुंजी हटाई जा सकती है। यदि आप SAML सिंगल साइन-ऑन का उपयोग करते हैं, तो आपके पहचान प्रदाता में डीप्रोविजनिंग साइन-इन को केंद्रीय रूप से संभालती है। SSH कुंजियों जैसी साइट-स्तरीय क्रेडेंशियल डैशबोर्ड में निरस्त की जाती हैं, और हटाने की प्रक्रिया स्वयं ऑडिट-लॉग की जाती है।

क्या टीम के सदस्य मेरी API कुंजी साझा करते हैं?

नहीं — लेकिन यह स्पष्ट करना आवश्यक है कि क्यों। API कुंजियाँ किसी व्यक्तिगत सदस्य की नहीं, बल्कि संगठन की होती हैं, और उनमें एक ही अनुमति कैटलॉग से जुड़ी उनकी अपनी सूक्ष्म अनुमतियाँ (granular scopes) होती हैं। इसलिए किसी व्यक्ति को कुंजी सौंपने के बजाय, आप उस काम के लिए सबसे सीमित दायरे (narrowest scope) वाली कुंजी बनाते हैं जो उस काम के लिए आवश्यक है, और काम समाप्त होने पर उस कुंजी को निरस्त कर देते हैं। गुप्त कुंजी (secret) का केवल एक हैश संग्रहीत किया जाता है, और प्रत्येक कुंजी यह रिकॉर्ड करती है कि उसका अंतिम बार उपयोग कब किया गया था ताकि उपयोग न की गई कुंजियों को खोजना और हटाना आसान हो।

क्या मैं सभी चीज़ों की चाबियाँ दिए बिना एक AI एजेंट को कनेक्ट कर सकता हूँ?

हाँ। हमारा MCP सर्वर OAuth 2.1 के साथ एजेंटों को प्रमाणित करता है और उन्हें आपके संगठन तथा आपकी RBAC भूमिका के दायरे में रखता है, जिसमें प्रति-टूल निरस्त करने योग्य टोकन होते हैं, ताकि आप संपूर्ण पहुँच देने के बजाय एक विशिष्ट क्षमता प्रदान करें। विनाशकारी कार्रवाइयों के लिए पुष्टि की आवश्यकता होती है, खर्च की सीमाएँ लागू होती हैं, और हर कार्रवाई मानव गतिविधि की तरह ही समान ऑडिट लॉग में दर्ज होती है।

एक टेनेंट को दूसरे टेनेंट के डेटा तक पहुँचने से क्या रोकता है?

Postgres पंक्ति-स्तरीय सुरक्षा (Row-Level Security) डेटाबेस में ही कॉलर के संगठन सबट्री तक क्वेरी को सीमित करती है, जिसमें एप्लिकेशन-स्तरीय फ़िल्टर एकमात्र पंक्ति के बजाय सुरक्षा की दूसरी परत (defence in depth) के रूप में कार्य करता है। दायरे से बाहर के रिकॉर्ड के अनुरोध पर अनुमति त्रुटि (permission error) के बजाय नॉट-फाउंड लौटाया जाता है, जिससे यह पता नहीं चलता कि क्या मौजूद है। सर्वर साइड पर, CageFS के माध्यम से प्रति-साइट आइसोलेशन (per-site isolation) प्रत्येक टेनेंट की शेल और फ़ाइलों को उनकी अपनी साइट तक सीमित रखता है।

क्या मैं भुगतान करने से पहले इसे आज़मा सकता हूँ?

हाँ। 14-दिन का ट्रायल कार्ड-मुक्त है — कोई भुगतान विवरण नहीं, कोई प्रतिबद्धता नहीं — और इसमें Footprint-Free होस्टिंग के साथ पाँच साइटों तक शामिल हैं। यह किसी सहकर्मी को आमंत्रित करने, भूमिका असाइन करने, और प्रतिबद्ध होने से पहले आपकी आवश्यकता के अनुसार सीमाओं के व्यवहार की पुष्टि करने के लिए पर्याप्त है।

एक ऐसी सीमा के साथ काम सौंपें जिस पर आप उंगली उठा सकें

बिना कार्ड के 14-दिन के निःशुल्क परीक्षण की शुरुआत करें, किसी को आमंत्रित करें, और अनुमति मॉडल को अपना काम करते हुए देखें — ऐसी भूमिकाएँ जिन्हें आप नाम दे सकते हैं, ऐसे दायरे जिन्हें आप रद्द कर सकते हैं, और एक ऑडिट लॉग जो बिल्कुल बताता है कि किसने क्या किया।

निःशुल्क शुरू करें