यदि कोई भी लॉग-इन उपयोगकर्ता अन्य उपयोगकर्ताओं की पंक्तियों को पढ़ सकता है, तो आपका डेटाबेस ऐप पर भरोसा कर रहा है कि वह सही व्यवहार करेगा। मैं रो-लेवल सुरक्षा नीतियों और भूमिकाओं के साथ नियम को PostgreSQL में ही ले जाता हूँ, फिर परीक्षणों से यह साबित करता हूँ कि एक उपयोगकर्ता दूसरे उपयोगकर्ता के डेटा तक नहीं पहुँच सकता है।
मैं PostgreSQL रो-लेवल सुरक्षा सेट करूँगा ताकि प्रत्येक उपयोगकर्ता केवल अपना डेटा देख सके, जिसमें Supabase भी शामिल है।
अधिकतम 5 तालिकाओं की रो-लेवल सुरक्षा समीक्षा, प्रत्येक अंतर को एक क्वेरी द्वारा दिखाया गया है।
- 5 तालिकाओं तक की समीक्षा
- लिखित रिपोर्ट
- उदाहरण प्रश्न
अधिकतम 10 तालिकाओं पर नीतियां और भूमिकाएं, परीक्षणों के साथ जो नियमों को सिद्ध करते हैं।
- अधिकतम 10 तालिकाओं पर नीतियां
- लिखित रिपोर्ट
- उदाहरण प्रश्न
अधिकतम 25 तालिकाएं, डेटाबेस में योजना सीमाएं, CI में माइग्रेशन और परीक्षण।
- अधिकतम 25 तालिकाएं, योजना सीमाएं, CI
- लिखित रिपोर्ट
- उदाहरण प्रश्न
एक कस्टम ऑफ़र का अनुरोध करें
कस्टम ऑफर का अनुरोध करने के लिए लॉग इन करें
इस Zinner से एक व्यक्तिगत प्रस्ताव का अनुरोध करने के लिए एक निःशुल्क खाता बनाएँ या लॉग इन करें।
लॉग इन / रजिस्टर करेंबिक्री-पूर्व प्रश्न पूछें
प्रश्न पूछने के लिए लॉग इन करें
प्लेटफ़ॉर्म स्पैम को कम करने के लिए, पूर्व-बिक्री संदेश केवल लॉग-इन उपयोगकर्ताओं द्वारा ही भेजे जा सकते हैं।
इस Zinner को सीधे संदेश भेजने के लिए एक निःशुल्क खाता बनाएँ या लॉग इन करें।
लॉग इन / रजिस्टर करेंलॉग इन आवश्यक है
इस Zinner को संदेश भेजने के लिए एक निःशुल्क खाता बनाएँ या लॉग इन करें।
लॉग इन / रजिस्टर करेंलॉग इन आवश्यक है
एक व्यक्तिगत ऑफ़र का अनुरोध करने के लिए एक निःशुल्क खाता बनाएँ या लॉग इन करें।
लॉग इन / रजिस्टर करेंएक नज़र में
यह तय करने में आपकी मदद करने के लिए इस सेवा के बारे में मुख्य विवरण। Zinn Hub द्वारा जेनरेट किया गया, विक्रेता द्वारा नहीं।
मूल्य स्थिति
प्रवर्तन परत
समर्थित प्लेटफ़ॉर्म
कार्य का प्रमाण
वितरण प्रारूप
आपको क्या मिलेगा
पूर्ण विवरण
उपयोगकर्ता खातों, सशुल्क योजनाओं या एक डेटाबेस में कई टीमों वाले किसी भी ऐप को यह तय करना होगा कि कौन सी पंक्तियों को कौन देख सकता है। यदि वह नियम केवल ऐप कोड में रहता है, तो यह पहली बार विफल हो जाता है जब कोई डेटा तक दूसरे तरीके से पहुंचता है: एक नया एंडपॉइंट जिसे कोई गार्ड करना भूल गया, उसी डेटाबेस पर एक दूसरा ऐप, या एपीआई जिसे Supabase आपकी तालिकाओं के लिए उत्पन्न करता है। रो-लेवल सुरक्षा नियम को वहां रखती है जहां डेटा है।
मैंने NDA के तहत एक सदस्यता उत्पाद पर यह किया है: तालिकाओं पर रो-लेवल सुरक्षा नीतियां और प्रत्येक सदस्यता स्तर के लिए एक अलग डेटाबेस भूमिका, ताकि एक योजना में क्या शामिल है, उसे PostgreSQL द्वारा लागू किया जाए, न कि किसी ऐसे चेक द्वारा जिसे कोई भूल सकता है।
स्टार्टर में, मैं उन नीतियों की समीक्षा करता हूं जो अधिकतम पांच तालिकाओं में हैं या नहीं हैं और अंतराल की एक लिखित सूची भेजता हूं, प्रत्येक को दिखाने वाली एक उदाहरण क्वेरी के साथ। मानक अधिकतम दस तालिकाओं पर नीतियां लिखता या ठीक करता है, आपके ऐप को आवश्यक भूमिकाएं सेट करता है, उन्हें माइग्रेशन फ़ाइलों के रूप में वितरित करता है, और परीक्षण जोड़ता है जिसमें उपयोगकर्ता A उपयोगकर्ता B की पंक्तियों को पढ़ने और बदलने की कोशिश करता है और विफल रहता है। उन्नत अधिकतम पच्चीस तालिकाओं को कवर करता है, डेटाबेस में लागू योजना या स्तर सीमाएं जोड़ता है, और CI में परीक्षण चलाता है।
Supabase पर, वही PostgreSQL सुविधाएँ लागू होती हैं, जिसमें auth.uid() और JWT दावे नीतियों के अंदर उपयोग किए जाते हैं। सादे PostgreSQL पर, नीतियां एक सत्र सेटिंग से वर्तमान उपयोगकर्ता को पढ़ती हैं जिसे आपका बैकएंड प्रत्येक अनुरोध के लिए सेट करता है।
कोई कॉल नहीं। प्रत्येक पैकेज इस बात पर एक सादे-भाषा के नोट के साथ समाप्त होता है कि कौन क्या देख सकता है; मानक और उन्नत पर, नीतियां आपके रिपॉजिटरी में माइग्रेशन के रूप में भी आती हैं, परीक्षणों के साथ। डिलीवरी के 14 दिनों के बाद, मैं कुछ भी ठीक करता हूं जो हमारे समझौते के अनुसार काम नहीं करता है, मुफ्त में।
अपने प्रोजेक्ट को पूरा करने के लिए कदम
1. डेटा को मैप करें - मैं तालिकाओं को सूचीबद्ध करता हूं, प्रत्येक पंक्ति का मालिक कौन है, और इसे कौन पढ़ना या बदलना चाहिए: मालिक, टीम के सदस्य, व्यवस्थापक, प्रत्येक योजना।
2. मौजूदा की समीक्षा करें - वर्तमान नीतियों, अनुदानों और भूमिकाओं की उस मानचित्र के खिलाफ जांच की जाती है, और हर अंतर को एक क्वेरी के साथ लिखा जाता है जो इसे दिखाता है।
3. नीतियां और भूमिकाएं - नीतियां प्रति तालिका और प्रति कार्रवाई लिखी जाती हैं, जिसमें योजनाओं या टीमों के लिए भूमिकाएं होती हैं, जैसे माइग्रेशन फाइलें जिनकी आप समीक्षा कर सकते हैं।
4. इसे साबित करें - परीक्षण विभिन्न उपयोगकर्ताओं के रूप में लॉग इन करते हैं और एक-दूसरे के डेटा को पढ़ने और बदलने का प्रयास करते हैं। हर निषिद्ध कार्रवाई विफल होनी चाहिए, और हर अनुमत कार्रवाई काम करनी चाहिए।
5. हैंडओवर - सादे शब्दों में एक छोटा नोट कि कौन क्या देख सकता है, माइग्रेशन, और जब एक नई तालिका दिखाई देती है तो एक नीति कैसे जोड़ें।
Zinner गुणवत्ता गारंटी
प्लेटफ़ॉर्म में शामिल होने से पहले हर Zinner की समीक्षा की जाती है और उसे अनुमोदित किया जाता है।
सभी सेवाएँ हमारी गुणवत्ता आश्वासन प्रतिबद्धता द्वारा समर्थित हैं।
आपके द्वारा दिए गए काम को मंज़ूरी देने तक आपका भुगतान सुरक्षित है।
पैकेजों की तुलना करें
| फ़ंक्शन | स्टार्टर | मानक | उन्नत |
|---|---|---|---|
| डिलीवरी का समय | 2 दिन | 5 दिन | 10 दिन |
| संशोधन | 1 | 2 | 3 |
| दायरा | 5 तालिकाओं तक की समीक्षा | 10 तालिकाओं तक की नीतियां | 25 तालिकाओं तक, योजना सीमाएं, CI |
| लिखित रिपोर्ट | ✓ | ✓ | ✓ |
| उदाहरण प्रश्न | ✓ | ✓ | ✓ |
सेवा विवरण
अक्सर पूछे जाने वाले प्रश्न
ऐप जांच उन रास्तों की रक्षा करती है जिन्हें आप याद रखते हैं। पंक्ति-स्तर की सुरक्षा आपके ऐप की डेटाबेस भूमिकाओं के तहत चलने वाली हर क्वेरी को कवर करती है, जिसमें बाद में जोड़े गए एंडपॉइंट और Supabase के API के लिए सीधे कॉल शामिल हैं। सुपरयूजर, तालिका मालिक और Supabase की सेवा कुंजी इसे डिज़ाइन द्वारा बायपास करती है, यही कारण है कि वे क्रेडेंशियल सर्वर पर रहते हैं। अधिकांश टीमें दोनों प्रकार की जांच रखती हैं।
यह हो सकता है, यदि कोई नीति एक धीमी फ़ंक्शन को कॉल करती है या एक इंडेक्स को याद करती है। मैं इसे ध्यान में रखते हुए नीतियां लिखता हूं, और समीक्षा किसी भी नीति को सूचीबद्ध करती है जिसे एक इंडेक्स की आवश्यकता होती है।
नहीं। डेटा के बिना एक स्कीमा नीतियों को लिखने और परीक्षण करने के लिए पर्याप्त है। परीक्षण मेरे द्वारा बनाए गए बीज डेटा पर चलते हैं।
नहीं। इस रूप में पंक्ति-स्तर की सुरक्षा एक PostgreSQL सुविधा है, और यह सेवा PostgreSQL के आसपास बनाई गई है।
ग्राहक समीक्षाएँ
देखें कि हमारे ग्राहक इस Zinn के बारे में क्या कहते हैं
श्रेणियाँ
Zinner नीतियां
संबंधित Zinns
