Auth - المصادقة وإدارة المستخدمين من Supabase

Auth هو خادم إدارة مستخدمين ومصادقة مكتوب بلغة Go يدعم ميزات Supabase مثل:

• إصدار JWTs
• أمان مستوى الصفوف مع PostgREST
• إدارة المستخدمين
• تسجيل الدخول بالبريد الإلكتروني وكلمة المرور والرابط السحري ورقم الهاتف
• تسجيل الدخول عبر موفري خارجيين (Google, Apple, Facebook, Discord, ...)

وهو مبني في الأصل على قاعدة الشيفرة الممتازة GoTrue من Netlify، ومع ذلك فقد تباعد الاثنان بشكل كبير في الميزات والإمكانيات.

إذا كنت ترغب في المساهمة في المشروع، فيرجى الرجوع إلى دليل المساهمة.

جدول المحتويات

• بدء سريع
• التشغيل في الإنتاج
• الإعدادات
• نقاط النهاية

بدء سريع

أنشئ ملف .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: `./auth`

### إذا كان Docker مثبّتًا لديك

أنشئ ملف `.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. هذا كل شيء! قم بزيارة [نقطة فحص الصحة](http://localhost:9999/health) للتأكد من أن auth يعمل.

## التشغيل في الإنتاج

تشغيل خادم مصادقة في الإنتاج ليس بالأمر السهل. نوصي باستخدام [Supabase Auth](https://supabase.com/auth) الذي يحصل على تحديثات أمنية منتظمة.

بخلاف ذلك، يرجى التأكد من إعداد عملية لتحديث الإصدار الأحدث على الفور. يمكنك القيام بذلك بمتابعة هذا المستودع، وتحديدًا قسمي [الإصدارات](https://github.com/supabase/auth/releases) و[النشرات الأمنية](https://github.com/supabase/auth/security/advisories).

### التوافق العكسي

يستخدم Auth نظام [الإصدارات الدلالية](https://semver.org). فيما يلي بعض التوضيحات الإضافية حول ضمانات التوافق العكسي:

**توافق واجهة برمجة التطبيقات Go**

ليست Auth مصممة للاستخدام كمكتبة Go. لا توجد ضمانات على توافق واجهة برمجة التطبيقات الخلفي عند استخدامها بهذه الطريقة بغض النظر عن أي رقم إصدار يتغير.

**التصحيح**

التغييرات في إصدار التصحيح تضمن التوافق العكسي مع:

- كائنات قاعدة البيانات (الجداول، الأعمدة، الفهارس، الدوال).
- REST API
- بنية JWT
- الإعدادات

أمثلة مضمونة:

- لن يغيّر العمود نوعه.
- لن يغيّر الجدول مفتاحه الأساسي.
- لن تتم إزالة فهرس.
- لن تتم إزالة قيد التفرد.
- لن تتم إزالة REST API.
- ستعمل وسائط REST APIs بشكل مكافئ كما في السابق (أو أفضل، إذا تم إصلاح خطأ برمجي).
- لن تتغير الإعدادات.

أمثلة غير مضمونة:

- قد يضيف الجدول أعمدة جديدة.
- قد تتم إعادة ترتيب الأعمدة في الجدول.
- قد تتم إزالة القيود غير الفريدة (فحوصات مستوى قاعدة البيانات، القيم الفارغة، القيم الافتراضية).
- قد يضيف JWT خصائص جديدة.

**الإصدار الثانوي**

التغييرات في الإصدار الثانوي تضمن التوافق العكسي مع:

- REST API
- بنية JWT
- الإعدادات

لن يُستثنى من هذه الضمانات إلا عند اكتشاف مشكلات أمنية خطيرة لا يمكن معالجتها بأي طريقة أخرى.

أمثلة مضمونة:

- قد يتم إهمال الواجهات البرمجية الحالية (APIs) لكنها تستمر في العمل خلال الإصدارات الثانوية القليلة القادمة.
- قد تصبح تغييرات الإعدادات قديمة لكنها تستمر في العمل لعدة إصدارات ثانوية قادمة.
- سيتم قبول JWTs الصادرة بالفعل، لكن قد تكون JWTs الجديدة ببنية مختلفة (وإن كانت مشابهة عادةً).

أمثلة غير مضمونة:

- إزالة حقول JWT بعد إشعار الإهمال.
- إزالة بعض واجهات API بعد إشعار الإهمال.
- إزالة تسجيل الدخول عبر المزودين الخارجيين بعد إشعار الإهمال.
- حذف أو اقتطاع أو تغييرات كبيرة في مخطط الجداول أو الفهارس أو العروض أو الدوال.

نهدف إلى توفير إشعار إهمال في سجلات التنفيذ لما لا يقل عن إصدارين رئيسيين أو أسبوعين إذا صدرت إصدارات متعددة. سيتم ضمان التوافق طالما كان الإشعار ساريًا.

**الإصدار الرئيسي**

التغييرات في الإصدار الرئيسي لا تضمن أي توافق عكسي مع الإصدارات السابقة.

### الميزات الموروثة

بعض الميزات الموروثة من قاعدة شيفرة Netlify غير مدعومة من Supabase وقد تتم إزالتها دون إشعار مسبق في المستقبل. هذه قائمة شاملة بتلك الميزات:

1. تعدد الإيجارات عبر جدول `instances` أي معامل الإعداد `GOTRUE_MULTI_INSTANCE_MODE`.
2. مستخدم النظام (مستخدم UUID الصفري).
3. المشرف الفائق عبر عمود `is_super_admin`.
4. معلومات المجموعة في JWTs عبر `GOTRUE_JWT_ADMIN_GROUP_NAME` وحقول إعداد أخرى.
5. توقيع JWT. يدعم Supabase Auth المفاتيح غير المتماثلة (RS256 افتراضيًا؛ ECC/Ed25519 اختياري). لا يزال HS256 مدعومًا للتوافق، لكن يُوصى بالترحيل إلى المفاتيح غير المتماثلة لسهولة التحقق والتدوير. سيتم الإعلان عن عمليات الإهمال المستقبلية في سجل التغييرات. راجع [مفاتيح توقيع JWT](https://supabase.com/docs/guides/auth/signing-keys) ودليل [JWTs](https://supabase.com/docs/guides/auth/jwts) للتفاصيل.

لاحظ أن هذه القائمة ليست شاملة وقد تتغير.

### أفضل الممارسات عند الاستضافة الذاتية

فيما يلي بعض أفضل الممارسات التي يجب اتباعها عند الاستضافة الذاتية لضمان التوافق العكسي مع Auth:

1. لا تعدّل مخطط قاعدة البيانات الذي يديره Auth. يمكنك الاطلاع على جميع الترحيلات في دليل `migrations`.
2. لا تعتمد على مخطط قاعدة البيانات وبنية البيانات فيها. استخدم دائمًا واجهات Auth البرمجية وJWTs لاستنتاج المعلومات عن المستخدمين.
3. شغّل Auth دائمًا خلف وكيل يدعم TLS مثل موازن التحميل أو CDN أو nginx أو أي برنامج مشابه.

## الإعدادات

يمكنك إعداد Auth باستخدام ملف إعدادات باسم `.env`، أو متغيرات البيئة، أو مزيج من الاثنين معًا. تُسبق متغيرات البيئة بالبادئة `GOTRUE_`، وستكون لها دائمًا الأولوية على القيم المقدمة عبر الملف.

### المستوى الأعلى```properties
GOTRUE_SITE_URL=https://example.netlify.com/

SITE_URL - string مطلوب

الرابط الأساسي الذي يستضيف موقعك. يُستخدم حاليًا مع إعدادات أخرى لإنشاء روابط تُستخدم في رسائل البريد الإلكتروني. أي URI يشترك في المضيف مع SITE_URL هو قيمة مسموح بها لمعاملات redirect_to (انظر /authorize وغيرها).

URI_ALLOW_LIST - string

قائمة مفصولة بفواصل من URIs (مثل "https://foo.example.com,https://*.foo.example.com,https://bar.example.com") مسموح بها كوجهات redirect_to صالحة. القيمة الافتراضية هي []. تدعم مطابقة أحرف البدل عبر globbing. على سبيل المثال https://*.foo.example.com سيسمح بقبول https://a.foo.example.com و https://b.foo.example.com. يتم دعم globbing أيضًا على النطاقات الفرعية. على سبيل المثال https://foo.example.com/* سيسمح بقبول https://foo.example.com/page1 و https://foo.example.com/page2.

لمزيد من أنماط glob الشائعة، راجع الرابط التالي.

OPERATOR_TOKEN - string وضع متعدد المثيلات فقط

السر المشترك مع مشغّل (عادةً Netlify) لهذه الخدمة المصغّرة. يُستخدم للتحقق من أن الطلبات قد مرت عبر المشغّل وأن قيم الحمولة يمكن الوثوق بها.

DISABLE_SIGNUP - bool

عند تعطيل التسجيل، الطريقة الوحيدة لإنشاء مستخدمين جدد هي عبر الدعوات. القيمة الافتراضية هي false، أي أن جميع عمليات التسجيل مفعّلة.

GOTRUE_EXTERNAL_EMAIL_ENABLED - bool

استخدم هذا لتعطيل التسجيل عبر البريد الإلكتروني (لا يزال بإمكان المستخدمين استخدام موفري OAuth الخارجيين للتسجيل / تسجيل الدخول)

GOTRUE_EXTERNAL_PHONE_ENABLED - bool

استخدم هذا لتعطيل التسجيل عبر الهاتف (لا يزال بإمكان المستخدمين استخدام موفري OAuth الخارجيين للتسجيل / تسجيل الدخول)

GOTRUE_RATE_LIMIT_HEADER - string

الترويسة التي يتم على أساسها تحديد معدل الطلبات لنقطة النهاية /token. من المتوقع أن يتم تعيين هذه الترويسة بواسطة وكيل وسيط موثوق (مثل Kong أو Envoy). الترويسات مثل x-forwarded-for قابلة للانتحال ولا يمكن الوثوق بها لتحديد معدل الطلبات عندما يتم توفيرها مباشرة من العميل.

GOTRUE_RATE_LIMIT_EMAIL_SENT - string