التكامل مع Supabase

Logto هو مزود حديث لخدمات التوثيق يقدم دعم تسجيل دخول آمن وشامل وسهل الاستخدام للتطبيقات. كما يقدم مجموعة كبيرة من SDKs وأدلة التكامل عبر أطر عمل ولغات برمجة متعددة، مما يمكنك من دمج خدمات توثيق الهوية من الدرجة المؤسسية في تطبيقك في غضون دقائق.

يركز هذا المقال بشكل أساسي على شرح كيفية دمج Supabase مع Logto.

أساسيات Supabase#

يستخدم Supabase الأمان على مستوى الصف في Postgres للسيطرة على أذونات الوصول إلى البيانات. ببساطة، عن طريق إنشاء سياسات الأمان على مستوى الصفوف للجداول في قاعدة البيانات، يمكننا تقييد وإدارة من يمكنه قراءة وكتابة وتحديث البيانات في الجدول.

لنفرض أن لديك جدولًا باسم "posts" في قاعدة البيانات الخاصة بك، مع المحتوى التالي:

يمثل الحقل user_id في الجدول المستخدم الذي ينتمي إليه كل بيانات المنشور. يمكنك تقييد كل مستخدم للوصول فقط إلى بيانات المنشورات الخاصة به بناءً على الحقل user_id.

ومع ذلك، قبل أن يمكن تنفيذ ذلك، يحتاج Supabase إلى أن يكون قادرًا على تحديد المستخدم الحالي الذي يصل إلى قاعدة البيانات.

إضافة بيانات المستخدم إلى طلبات Supabase#

بفضل دعم Supabase لـ JWT، عندما يتفاعل تطبيقنا مع Supabase، يمكننا توليد JWT يحتوي على بيانات المستخدم باستخدام السر الذي يقدمه Supabase. ثم نستخدم هذا JWT كعنوان مصادقة عند إجراء الطلبات. عند تلقي الطلب، يتحقق Supabase تلقائيًا من صلاحية JWT ويسمح بالوصول إلى البيانات الموجودة بداخله على مدار العمليات التالية.

أولاً، يمكننا الحصول على السر JWT الذي يقدمه Supabase من "إعدادات المشروع" في لوحة إدارة Supabase:

ثم، عندما نستخدم SDK Supabase لإجراء طلبات إلى Supabase، نستخدم هذا السر لتوليد JWT الخاص بنا وإرفاقه كعنوان مصادقة للطلب. (يرجى ملاحظة أن هذه العملية تحدث ضمن خدمة الخلفية الخاصة بتطبيقك ويجب عدم كشف سر JWT لأطراف ثالثة).

بعد ذلك، انتقل إلى محرر SQL في لوحة إدارة Supabase وأنشئ دالة لاستخراج userId الذي يُحمَل في الطلب:

الكود المستخدم في الصورة هو كما يلي:

كما يظهر الكود، في Supabase يمكنك استخراج الحزمة الخاصة بـ JWT الذي نقوم بتوليده عن طريق استدعاء request.jwt.claims. يعتبر الحقل userId داخل الحزمة هو القيمة التي قمنا بتعيينها.

مع هذه الدالة، يمكن لـ Supabase تحديد المستخدم الذي يصل حاليًا إلى قاعدة البيانات.

إنشاء سياسة الأمان على مستوى الصفوف#

بعد ذلك، يمكننا إنشاء سياسة الأمان على مستوى الصفوف لتقييد كل مستخدم ليصل فقط إلى بيانات المنشورات الخاصة به بناءً على الحقل user_id في جدول المنشورات.

1. توجه إلى صفحة محرر الجداول في لوحة إدارة Supabase واختر جدول المنشورات.
2. انقر على "إضافة سياسة RLS" في أعلى الجدول.
3. في النافذة التي تُطالَب بها، انقر على "إنشاء سياسة".
4. أدخل اسم السياسة واختر أمر سياسة SELECT.
5. في الكتلة using من الكود أدناه، أدخل:

من خلال استخدام مثل هذه السياسات، يتم تحقيق التحكم في الوصول إلى البيانات داخل Supabase.

في التطبيقات الواقعية، ستقوم بإنشاء سياسات متنوعة لتقييد إجراءات المستخدم مثل إدخال البيانات وتعديلها. ومع ذلك، فإن هذا يتجاوز نطاق هذا المقال. لمزيد من المعلومات حول الأمان على مستوى الصفوف (RLS)، يرجى الرجوع إلى تأمين بياناتك باستخدام أمان الصفوف في Postgres.

عملية التكامل الأساسية مع Logto#

كما ذكرنا سابقًا، نظرًا لأن Supabase يستخدم RLS لأغراض التحكم في الوصول، فإن المفتاح للتكامل مع Logto (أو أي خدمة توثيق أخرى) يكمن في الحصول على معرف المستخدم للمستخدم المخول وإرساله إلى Supabase. تم توضيح العملية الكاملة في الرسم البياني أدناه:

التالي، سنشرح كيفية دمج Logto مع Supabase بناءً على مخطط العملية هذا.

تكامل Logto#

يوفر Logto أدلة تكامل لأطر عمل ولغات برمجة متنوعة.

بشكل عام، التطبيقات المبنية بهذه الأطر واللغات تندرج ضمن فئات مثل التطبيقات الأصلية، وتطبيقات الصفحة الواحدة (SPA)، وتطبيقات الويب التقليدية، وتطبيقات الجهاز إلى الجهاز (M2M). يمكنك زيارة صفحة البدايات السريعة لـ Logto لدمج Logto في تطبيقك بناءً على التقنية التي تستخدمها. بعد ذلك، اتبع التعليمات أدناه لدمج Logto في مشروعك بناءً على نوع التطبيق الخاص بك.

التطبيق الأصلي أو SPA#

كلا التطبيقين الأصليين و SPAs يعملان على جهازك، ويتم تخزين بيانات الاعتماد (رمز الوصول) الذي تم الحصول عليه بعد تسجيل الدخول محليًا على جهازك.

لذلك، عند دمج تطبيقك مع Supabase، تحتاج إلى التفاعل مع Supabase من خلال خدمة الخلفية الخاصة بك لأنك لا تستطيع كشف المعلومات الحساسة (مثل سر JWT لـ Supabase) على جهاز كل مستخدم.

افترض أنك تبني SPA باستخدام React و Express. لقد نجحت في دمج Logto في تطبيقك باتباع دليل Logto لـ React SDK (يمكنك الرجوع إلى الكود في عينة React في مستودعنا). بالإضافة إلى ذلك، لقد قمت بإضافة التحقق من رمز الوصول لـ Logto إلى خادم الخلفية الخاص بك وفقًا لوثائق حماية API الخاص بك على Node (Express).

التالي، ستستخدم رمز الوصول الذي تم الحصول عليه من Logto لطلب بيانات المستخدم من خادم الخلفية الخاص بك:

في خادم الخلفية الخاص بك، لقد قمت بالفعل باستخراج معرف المستخدم المسجل الدخول من رمز الوصول باستخدام ميدل وير:

الآن يمكنك استخدام getSupabaseClient الموضح أعلاه لإرفاق userId بـ JWT المستخدم في الطلبات اللاحقة إلى Supabase. بدلاً من ذلك، يمكنك إنشاء ميدل وير لإنشاء عميل Supabase للطلبات التي تحتاج إلى التفاعل مع Supabase:

في تدفق المعالجة التالي، يمكنك استدعاء ctx.supabase مباشرة للتفاعل مع Supabase:

في هذا الكود، سيعيد Supabase فقط بيانات المنشورات التي تخص المستخدم الحالي بناءً على السياسات التي تم تعيينها مسبقًا.

تطبيق الويب التقليدي#

الفرق الرئيسي بين تطبيق الويب التقليدي والتطبيق الأصلي أو SPA هو أن تطبيق الويب التقليدي يقوم بتصحيح الصفحات وتحديثها بشكل كامل على خادم الويب. لذلك يتم إدارة بيانات المستخدم مباشرة عن طريق خادم الويب، بينما في التطبيقات الأصلية و SPAs، توجد البيانات على جهاز المستخدم.

عند دمج Logto مع تطبيق ويب تقليدي في Supabase، يمكنك استخراج معرف المستخدم المسجل الدخول مباشرة من الخلفية.

باستخدام مشروع Next.js كمثال، بعد دمج Logto مع مشروعك باتباع دليل SDK لـ Next.js، يمكنك استخدام SDK لـ Logto لاستخراج معلومات المستخدم وبناء JWT المناسب للتفاعل مع Supabase.

تطبيق الجهاز إلى الجهاز#

غالباً ما يُستخدم الجهاز إلى الجهاز (M2M) عندما يحتاج تطبيقك إلى التواصل مباشرة مع خوادم الموارد، مثل خدمة ثابتة تجلب المنشورات اليومية، إلخ.

يمكنك استخدام دليل الجهاز إلى الجهاز: تحقق مع Logto لمصادقة تطبيق الجهاز إلى الجهاز. التكامل بين Supabase وتطبيقات الجهاز إلى الجهاز يشبه تكامل التطبيقات الأصلية و SPAs (كما هو موضح في قسم "التطبيق الأصلي أو تطبيق الصفحة الواحدة"). يتضمن الحصول على رمز الوصول من Logto ثم التحقق منه عبر API محمي في الخلفية.

ومع ذلك، من المهم ملاحظة أن التطبيقات الأصلية و SPAs عادة ما يتم تصميمها للمستخدمين النهائيين، لذا فإن معرف المستخدم الذي يتم الحصول عليه يمثل المستخدم نفسه. بينما يمثل رمز الوصول لتطبيقات الجهاز إلى الجهاز التطبيق نفسه، والحقل sub في حمولة رمز الوصول هو معرف العميل للتطبيق M2M وليس مستخدمًا محددًا. لذلك، أثناء التطوير، من المهم التمييز بين البيانات المقصودة لتطبيقات M2M.

علاوة على ذلك، إذا كنت ترغب في أن يتمكن تطبيق M2M المحدد من الوصول إلى Supabase نيابة عن الخدمة بأكملها لتجاوز قيود RLS، يمكنك استخدام السر service_role لـ Supabase لإنشاء عميل Supabase. إنه مفيد عندما تريد تنفيذ بعض المهام الإدارية أو الآلية التي تتطلب الوصول إلى جميع البيانات بدون أن تكون مقيدة بسياسات الأمان على مستوى الصفوف المُعدة للمستخدمين الفرديين.

يمكنك العثور على السر service_role في نفس الصفحة التي يتم فيها العثور على سر JWT:

عند إنشاء عميل Supabase، استخدم السر service_role، ثم يمكن لهذا العميل الوصول إلى جميع البيانات في قاعدة البيانات:

الخلاصة#

في هذه المقالة، نتعمق في دمج Logto مع Supabase، موضحين رؤى رئيسية وجوانب هامة في التكامل. نستكشف مفاهيم مثل مصادقة JWT وسياسات الأمان على مستوى الصفوف، ونوجهك خلال عملية دمج Logto بشكل سلس في التطبيقات التي تعتمد على Supabase. مع هذه المعرفة، نأمل أن تتمكن من تعزيز أمان التطبيق الخاص بك ووظائفه وحتى توسيع مشاريعك بميزات إضافية باقتدار.