تقسية منصة SaaS مبنية بـ React + Supabase (أمان + صلاحيات + دفع + Webhooks)
تفاصيل المشروع
لدي منصة SaaS اسمها Sanadk مبنية بسرعة عبر أدوات AI (Lovable) على التكديس التالي:
Frontend: React + TypeScript
Backend: Supabase (Postgres + RLS + Storage)
Edge Functions: Supabase Functions (Deno)
Payments: تدفق دفع يعتمد على Webhooks وتفعيل اشتراك/خدمة
أحتاج مستقل خبير لتنفيذ تقسية كاملة للمنصة قبل الإطلاق العام، بدون إعادة بناء وبدون تغيير التقنية.
نطاق العمل المطلوب (التسليمات النهائية)
1) تقرير تقسية (Audit Report) + خطة إصلاح
فحص كامل للكود في GitHub + migrations + edge functions
تقرير مخاطر مرتب حسب الأولوية (Critical / High / Medium / Low)
خطة إصلاح عملية مرتبطة بمواقع الملفات (paths) وخطوات اختبار واضحة
2) تنفيذ الإصلاحات الأساسية (Hardening Implementation)
تشمل على الأقل:
تضييق Supabase RLS (عزل بيانات المستخدم/المنشأة ومنع أي تسرب بيانات)
تضييق Storage policies للفواتير/الإيصالات/الملفات بحيث المستخدم لا يصل إلا لملفاته (والأدمن فقط عند الحاجة)
تأمين RPCs الحساسة (عدم السماح بتنفيذها من anon/authenticated إذا كانت حساسة، وحصرها وفق نموذج آمن)
تأمين Edge Functions الحساسة (مثل manual activation / cron processing) عبر JWT role checks أو signed secret header
تطبيق Idempotency/Dedup للـ webhooks لمنع تكرار المعالجة والتفعيل
تحسين تسجيل الأحداث في مسار الدفع (correlation IDs + logs منظمة)
3) اختبار Staging وتسليم تقرير تحقق
تطبيق التغييرات على بيئة Staging (أو تقديم تعليمات تطبيق دقيقة إذا رغبت أنا بالتطبيق)
اختبار مسارات حرجة: تسجيل الدخول، الدفع، webhooks، التفعيل، رفع/تنزيل الملفات
تقرير نهائي: ما تم إصلاحه + ما تبقى + توصيات لاحقة
قواعد العمل (إلزامية)
العمل يتم عبر GitHub Branch + Pull Requests فقط (ممنوع تعديل مباشر على main)
لا يتم مشاركة أي Secrets (مفاتيح دفع / service_role / API keys). يجب استخدام env vars فقط
ممنوع تغيير التقنية أو إعادة البناء (نفس React + Supabase)
توثيق مختصر وواضح لكل PR وخطوات الاختبار
معايير القبول (Acceptance Criteria)
لا يمكن لأي مستخدم الوصول لبيانات/ملفات مستخدم آخر (RLS + Storage مثبتة بالاختبار)
webhooks لا تسبب أي تكرار تفعيل حتى مع إعادة الإرسال (idempotency)
وظائف/عمليات الدفع الحساسة محمية (لا استدعاء غير مصرح)
تسليم PRs منظمة + تقرير تقسية + تقرير اختبار Staging
المطلوب من المتقدم
أرسل في عرضك:
روابط/أمثلة لأعمال مشابهة (Supabase RLS أو Postgres Security أو Webhooks Payments)
تأكيد الالتزام بقواعد العمل أعلاه
خطة مختصرة جدًا من 5–7 نقاط لكيف ستنفذ المشروع خلال 14 يوم
العروض المقدمة
مروان ب.
مرحبا، اطلعت على تفاصيل منصة Sanadk والتكديس المستخدم، ولدي خبرة مباشرة في تقسية منصات SaaS مبنية على Supabase (Postgres RLS Edge Functions) بدون إعادة بناء أو ...
Muhanad I.
أهلا بك أخي الكريم، لقد قرأت متطلباتك بدقة، وبما أن منصة Sanadk تعتمد على Supabase و Lovable، فأنا أدرك تماما أهمية ضبط الـ RLS والـ Edge Functions لضمان عدم وج...
سليمان ر.
السلام عليكم، معاك سليمان مطور Full-Stack اشتغلت قبل كده على مشاريع بـ Supabase وكان فيها فصل واضح بين صلاحيات ال Admin والمستخدم العادي، بحيث الأدمن يشوف كل ال...
محمود ع.
السلام عليكم أستاذ عبدالله، معك محمود عباس، مطور منصات SaaS وخبرة مباشرة مع React وSupabase خصوصا في RLS وتأمين الـ Edge Functions وتدفقات الدفع المعتمدة على We...
احمد م.
مرحبا ا. عبدالله، قرأت وصف المشروع بعناية، وهذا النوع من تقسية منصات SaaS المبنية بـ React Supabase هو بالضبط مجال تخصصي. أعمل بشكل أساسي على تطبيقات ويب تعتمد ...
Ahmed N.
مرحبا، اطلعت بعناية على وصف منصة Sanadk ونطاق العمل المطلوب، وما تطلبه هنا ليس فحصا شكليا، بل تقسية حقيقية قبل الإطلاق العام وهذا بالضبط المجال الذي أعمل فيه. أ...
احمد ا.
حياك الله أ/عبدالله بحثت في تفاصيل المشروع اللي كاتبه وبما ان المنصة اتبنت بسرعة عبر AI tools، فده عادة بيخلي فيه gaps أمنية خطيرة خاصة في الأجزاء الحساسة زي RL...
عبدالرحمن م.
مرحبا، اطلعت على تفاصيل منصة Sanadk ونطاق العمل المطلوب، وبناء عليه أؤكد أنني قادر على تنفيذ تقسية أمنية كاملة (Security Hardening Audit) للمنصة قبل الإطلاق الع...
محمد س.
مرحبا أستاذ عبد الله، أشكرك على طرح هذا المشروع الواضح والدقيق، وبصراحة هو من النوع الذي يتطلب خبرة حقيقية في تقسية المنصات SaaS وليس مجرد برمجة تقليدية، ويسعدن...