मैं PostgreSQL रो-लेवल सुरक्षा सेट करूँगा ताकि प्रत्येक उपयोगकर्ता केवल अपना डेटा देख सके, जिसमें Supabase भी शामिल है।

उपयोगकर्ता खातों, सशुल्क योजनाओं या एक डेटाबेस में कई टीमों वाले किसी भी ऐप को यह तय करना होगा कि कौन सी पंक्तियों को कौन देख सकता है। यदि वह नियम केवल ऐप कोड में रहता है, तो यह पहली बार विफल हो जाता है जब कोई डेटा तक दूसरे तरीके से पहुंचता है: एक नया एंडपॉइंट जिसे कोई गार्ड करना भूल गया, उसी डेटाबेस पर एक दूसरा ऐप, या एपीआई जिसे Supabase आपकी तालिकाओं के लिए उत्पन्न करता है। रो-लेवल सुरक्षा नियम को वहां रखती है जहां डेटा है।

मैंने NDA के तहत एक सदस्यता उत्पाद पर यह किया है: तालिकाओं पर रो-लेवल सुरक्षा नीतियां और प्रत्येक सदस्यता स्तर के लिए एक अलग डेटाबेस भूमिका, ताकि एक योजना में क्या शामिल है, उसे PostgreSQL द्वारा लागू किया जाए, न कि किसी ऐसे चेक द्वारा जिसे कोई भूल सकता है।

स्टार्टर में, मैं उन नीतियों की समीक्षा करता हूं जो अधिकतम पांच तालिकाओं में हैं या नहीं हैं और अंतराल की एक लिखित सूची भेजता हूं, प्रत्येक को दिखाने वाली एक उदाहरण क्वेरी के साथ। मानक अधिकतम दस तालिकाओं पर नीतियां लिखता या ठीक करता है, आपके ऐप को आवश्यक भूमिकाएं सेट करता है, उन्हें माइग्रेशन फ़ाइलों के रूप में वितरित करता है, और परीक्षण जोड़ता है जिसमें उपयोगकर्ता A उपयोगकर्ता B की पंक्तियों को पढ़ने और बदलने की कोशिश करता है और विफल रहता है। उन्नत अधिकतम पच्चीस तालिकाओं को कवर करता है, डेटाबेस में लागू योजना या स्तर सीमाएं जोड़ता है, और CI में परीक्षण चलाता है।

Supabase पर, वही PostgreSQL सुविधाएँ लागू होती हैं, जिसमें auth.uid() और JWT दावे नीतियों के अंदर उपयोग किए जाते हैं। सादे PostgreSQL पर, नीतियां एक सत्र सेटिंग से वर्तमान उपयोगकर्ता को पढ़ती हैं जिसे आपका बैकएंड प्रत्येक अनुरोध के लिए सेट करता है।

कोई कॉल नहीं। प्रत्येक पैकेज इस बात पर एक सादे-भाषा के नोट के साथ समाप्त होता है कि कौन क्या देख सकता है; मानक और उन्नत पर, नीतियां आपके रिपॉजिटरी में माइग्रेशन के रूप में भी आती हैं, परीक्षणों के साथ। डिलीवरी के 14 दिनों के बाद, मैं कुछ भी ठीक करता हूं जो हमारे समझौते के अनुसार काम नहीं करता है, मुफ्त में।

अपने प्रोजेक्ट को पूरा करने के लिए कदम
1. डेटा को मैप करें - मैं तालिकाओं को सूचीबद्ध करता हूं, प्रत्येक पंक्ति का मालिक कौन है, और इसे कौन पढ़ना या बदलना चाहिए: मालिक, टीम के सदस्य, व्यवस्थापक, प्रत्येक योजना।
2. मौजूदा की समीक्षा करें - वर्तमान नीतियों, अनुदानों और भूमिकाओं की उस मानचित्र के खिलाफ जांच की जाती है, और हर अंतर को एक क्वेरी के साथ लिखा जाता है जो इसे दिखाता है।
3. नीतियां और भूमिकाएं - नीतियां प्रति तालिका और प्रति कार्रवाई लिखी जाती हैं, जिसमें योजनाओं या टीमों के लिए भूमिकाएं होती हैं, जैसे माइग्रेशन फाइलें जिनकी आप समीक्षा कर सकते हैं।
4. इसे साबित करें - परीक्षण विभिन्न उपयोगकर्ताओं के रूप में लॉग इन करते हैं और एक-दूसरे के डेटा को पढ़ने और बदलने का प्रयास करते हैं। हर निषिद्ध कार्रवाई विफल होनी चाहिए, और हर अनुमत कार्रवाई काम करनी चाहिए।
5. हैंडओवर - सादे शब्दों में एक छोटा नोट कि कौन क्या देख सकता है, माइग्रेशन, और जब एक नई तालिका दिखाई देती है तो एक नीति कैसे जोड़ें।