Auth - सुपाबेस द्वारा प्रमाणीकरण और उपयोगकर्ता प्रबंधन

Auth एक उपयोगकर्ता प्रबंधन और प्रमाणीकरण सर्वर है जो Go में लिखा गया है और Supabase की सुविधाओं को संचालित करता है, जैसे:

• JWTs जारी करना
• PostgREST के साथ रो लेवल सुरक्षा
• उपयोगकर्ता प्रबंधन
• ईमेल, पासवर्ड, मैजिक लिंक, फ़ोन नंबर से साइन इन करें
• बाहरी प्रदाताओं (Google, Apple, Facebook, Discord, ...) से साइन इन करें

यह मूल रूप से उत्कृष्ट नेटलिफ़ाई का GoTrue कोडबेस पर आधारित है, हालांकि दोनों सुविधाओं और क्षमताओं में काफी भिन्न हो चुके हैं।

यदि आप परियोजना में योगदान देना चाहते हैं, तो कृपया योगदान मार्गदर्शिका देखें।

विषय-सूची

• त्वरित प्रारंभ
• प्रोडक्शन में चलाना
• कॉन्फ़िगरेशन
• एंडपॉइंट्स

त्वरित प्रारंभ

अपने स्वयं के कस्टम एनवायरनमेंट वेरिएबल्स संग्रहीत करने के लिए एक .env फ़ाइल बनाएँ। देखें example.env

1. Postgres कंटेनर में स्थानीय Postgres डेटाबेस प्रारंभ करें: docker-compose -f docker-compose-dev.yml up postgres
2. auth बाइनरी बनाएँ: make build . आपको इस प्रकार का आउटपुट देखना चाहिए:```bash go build -ldflags "-X github.com/supabase/auth/cmd.Version=git rev-parse HEAD" GOOS=linux GOARCH=arm64 go build -ldflags "-X github.com/supabase/auth/cmd.Version=git rev-parse HEAD" -o gotrue-arm64

3. ऑथ बाइनरी निष्पादित करें: `./auth`

### यदि आपके पास Docker स्थापित है

अपने स्वयं के कस्टम env vars संग्रहीत करने के लिए एक `.env.docker` फ़ाइल बनाएँ। [`example.docker.env`](https://github.com/supabase/auth/blob/master/example.docker.env) देखें।

1. `make build`
2. `make dev`
3. `docker ps` में दो Docker कंटेनर (`auth-auth-1` और `auth-postgres-1`) दिखने चाहिए।
4. बस हो गया! यह पुष्टि करने के लिए कि auth चल रहा है, [health check endpoint](http://localhost:9999/health) पर जाएँ।

## प्रोडक्शन में चलाना

प्रोडक्शन में प्रमाणीकरण सर्वर चलाना आसान काम नहीं है। हम [Supabase Auth](https://supabase.com/auth) का उपयोग करने की अनुशंसा करते हैं, जिसे नियमित सुरक्षा अपडेट मिलते हैं।

अन्यथा, कृपया सुनिश्चित करें कि आप नवीनतम संस्करण में तुरंत अपडेट करने के लिए एक प्रक्रिया स्थापित करते हैं। आप इस रिपॉजिटरी का अनुसरण करके ऐसा कर सकते हैं, विशेष रूप से [Releases](https://github.com/supabase/auth/releases) और [Security Advisories](https://github.com/supabase/auth/security/advisories) अनुभागों का।

### बैकवर्ड संगतता

Auth [Semantic Versioning](https://semver.org) योजना का उपयोग करता है। बैकवर्ड संगतता गारंटियों पर कुछ और स्पष्टीकरण यहाँ दिए गए हैं:

**Go API संगतता**

Auth को Go लाइब्रेरी के रूप में उपयोग करने के लिए नहीं बनाया गया है। इस तरह उपयोग करने पर बैकवर्ड API संगतता की कोई गारंटी नहीं है, चाहे कोई भी संस्करण संख्या बदल जाए।

**पैच**

पैच संस्करण में परिवर्तन निम्नलिखित के साथ बैकवर्ड संगतता की गारंटी देता है:

- डेटाबेस ऑब्जेक्ट (टेबल, कॉलम, इंडेक्स, फ़ंक्शन)।
- REST API
- JWT संरचना
- कॉन्फ़िगरेशन

गारंटीशुदा उदाहरण:

- एक कॉलम का प्रकार नहीं बदलेगा।
- एक टेबल की प्राथमिक कुंजी नहीं बदलेगी।
- एक इंडेक्स नहीं हटाया जाएगा।
- एक विशिष्टता बाधा (uniqueness constraint) नहीं हटाई जाएगी।
- एक REST API को नहीं हटाया जाएगा।
- REST APIs के पैरामीटर पहले की तरह समान रूप से काम करेंगे (या बेहतर, यदि कोई बग ठीक किया गया है)।
- कॉन्फ़िगरेशन नहीं बदलेगा।

गारंटी रहित उदाहरण:

- एक टेबल नए कॉलम जोड़ सकती है।
- एक टेबल में कॉलम पुनः क्रमबद्ध हो सकते हैं।
- गैर-विशिष्ट बाधाएँ (non-unique constraints) हटाई जा सकती हैं (डेटाबेस स्तर की जाँच, null, डिफ़ॉल्ट मान)।
- JWT नए गुण जोड़ सकता है।

**माइनर**

माइनर संस्करण में परिवर्तन निम्नलिखित के साथ बैकवर्ड संगतता की गारंटी देता है:

- REST API
- JWT संरचना
- कॉन्फ़िगरेशन

इन गारंटियों के अपवाद केवल तभी बनाए जाएंगे जब गंभीर सुरक्षा समस्याएँ पाई जाती हैं जिन्हें किसी अन्य तरीके से ठीक नहीं किया जा सकता है।

गारंटीशुदा उदाहरण:

- मौजूदा APIs को पदावनत (deprecated) किया जा सकता है, लेकिन वे अगले कुछ माइनर संस्करण रिलीज़ के लिए काम करते रहेंगे।
- कॉन्फ़िगरेशन परिवर्तन पदावनत हो सकते हैं, लेकिन अगले कुछ माइनर संस्करण रिलीज़ के लिए काम करते रहेंगे।
- पहले से जारी JWT स्वीकार किए जाएंगे, लेकिन नए JWT एक अलग संरचना के साथ हो सकते हैं (लेकिन आमतौर पर समान)।

गारंटी रहित उदाहरण:

- पदावनति सूचना के बाद JWT फ़ील्ड्स को हटाना।
- पदावनति सूचना के बाद कुछ APIs को हटाना।
- पदावनति सूचना के बाद बाहरी प्रदाताओं के साथ साइन-इन को हटाना।
- टेबल, इंडेक्स, व्यू, फ़ंक्शन में विलोपन, छोटा करना (truncation), महत्वपूर्ण स्कीमा परिवर्तन।

हमारा लक्ष्य कम से कम दो प्रमुख संस्करण रिलीज़ या दो सप्ताह (यदि एकाधिक रिलीज़ निकलती हैं) के लिए निष्पादन लॉग में पदावनति सूचना प्रदान करना है। जब तक सूचना सक्रिय है, संगतता की गारंटी दी जाएगी।

**मेजर**

मेजर संस्करण में परिवर्तन पिछले संस्करणों के साथ किसी भी बैकवर्ड संगतता की गारंटी नहीं देते हैं।

### विरासत में मिली विशेषताएँ

Netlify कोडबेस से विरासत में मिली कुछ विशेषताएँ Supabase द्वारा समर्थित नहीं हैं और भविष्य में बिना पूर्व सूचना के हटाई जा सकती हैं। उन विशेषताओं की एक व्यापक सूची निम्नलिखित है:

1. `instances` टेबल के माध्यम से मल्टी-टेनेंसी, अर्थात `GOTRUE_MULTI_INSTANCE_MODE` कॉन्फ़िगरेशन पैरामीटर।
2. सिस्टम उपयोगकर्ता (शून्य UUID उपयोगकर्ता)।
3. `is_super_admin` कॉलम के माध्यम से सुपर एडमिन।
4. `GOTRUE_JWT_ADMIN_GROUP_NAME` और अन्य कॉन्फ़िगरेशन फ़ील्ड्स के माध्यम से JWT में समूह जानकारी।
5. JWT हस्ताक्षर। Supabase Auth असममित कुंजियों (डिफ़ॉल्ट रूप से RS256; ECC/Ed25519 वैकल्पिक) का समर्थन करता है। HS256 अभी भी संगतता के लिए समर्थित है, लेकिन आसान सत्यापन और रोटेशन के लिए असममित कुंजियों में माइग्रेट करने की अनुशंसा की जाती है। भविष्य की पदावनतियाँ (deprecations) चेंजलॉग में घोषित की जाएंगी। विवरण के लिए [JWT Signing Keys](https://supabase.com/docs/guides/auth/signing-keys) और [JWTs guide](https://supabase.com/docs/guides/auth/jwts) देखें।

ध्यान दें कि यह एक संपूर्ण सूची नहीं है और यह बदल सकती है।

### सेल्फ-होस्टिंग करते समय सर्वोत्तम अभ्यास

Auth के साथ बैकवर्ड संगतता सुनिश्चित करने के लिए सेल्फ-होस्टिंग करते समय पालन करने के लिए ये कुछ सर्वोत्तम अभ्यास हैं:

1. Auth द्वारा प्रबंधित स्कीमा को संशोधित न करें। आप `migrations` निर्देशिका में सभी माइग्रेशन देख सकते हैं।
2. डेटाबेस में डेटा की स्कीमा और संरचना पर निर्भर न रहें। उपयोगकर्ताओं के बारे में जानकारी का अनुमान लगाने के लिए हमेशा Auth APIs और JWT का उपयोग करें।
3. Auth को हमेशा TLS-सक्षम प्रॉक्सी के पीछे चलाएँ, जैसे लोड बैलेंसर, CDN, nginx या अन्य समान सॉफ़्टवेयर।

## कॉन्फ़िगरेशन

आप `.env` नामक कॉन्फ़िगरेशन फ़ाइल, पर्यावरण चर, या दोनों के संयोजन का उपयोग करके Auth को कॉन्फ़िगर कर सकते हैं। पर्यावरण चर `GOTRUE_` से उपसर्गित होते हैं, और फ़ाइल के माध्यम से दिए गए मानों पर हमेशा प्राथमिकता रखेंगे।

### टॉप-लेवल```properties
GOTRUE_SITE_URL=https://example.netlify.com/

SITE_URL - string आवश्यक

आपकी साइट जिस बेस URL पर स्थित है। वर्तमान में इसका उपयोग अन्य सेटिंग्स के साथ मिलकर ईमेल में उपयोग होने वाले URL बनाने के लिए किया जाता है। कोई भी URI जो SITE_URL के साथ एक ही होस्ट साझा करता है, redirect_to पैरामीटर के लिए अनुमत मान है (देखें /authorize आदि)।

URI_ALLOW_LIST - string

कॉमा-पृथक URI की सूची (जैसे "https://foo.example.com,https://*.foo.example.com,https://bar.example.com") जो मान्य redirect_to गंतव्य के रूप में अनुमत हैं। डिफ़ॉल्ट [] है। ग्लोबिंग के माध्यम से वाइल्डकार्ड मिलान का समर्थन करता है। जैसे https://*.foo.example.com https://a.foo.example.com और https://b.foo.example.com को स्वीकार करने की अनुमति देगा। सबडोमेन पर भी ग्लोबिंग समर्थित है। जैसे https://foo.example.com/* https://foo.example.com/page1 और https://foo.example.com/page2 को स्वीकार करने की अनुमति देगा।

अधिक सामान्य ग्लोब पैटर्न के लिए, निम्न लिंक देखें।

OPERATOR_TOKEN - string केवल मल्टी-इंस्टेंस मोड के लिए