الأمان

المصادقة

تُدار الحسابات بواسطة Supabase Auth بالبريد الإلكتروني وكلمة المرور، أو Google OAuth، أو GitHub OAuth. بعد تسجيل الدخول، يحمل متصفحك رمز جلسة (JWT) يُجدَّد تلقائياً بواسطة برمجية المنصة الوسيطة (middleware)، بحيث لا تنتهي صلاحية جلسة عاملة بصمت في منتصف العمل.

يقبل API رمز الجلسة ذاك بشكلين: كـ session cookie ترسلها لوحة التحكم على أي حال، أو كـ Authorization Bearer header. يستخدم الوصول البرمجي دون تسجيل دخول من المتصفح مفاتيح API بدلاً من ذلك، الموضحة أدناه. ترفض نقاط النهاية الطلبات دون بيانات اعتماد صالحة؛ فقط المسارات العامة صراحةً، مثل فحص السلامة ونموذج التواصل، تعمل دون مصادقة.

الأدوار والصلاحيات

لكل حساب دور واحد بالضبط: CLIENT أو OPERATOR أو ADMIN. يملك العملاء الروبوتات ويدفعون مقابل الجلسات، ويتحكم المشغلون بالروبوتات ويكسبون من الجلسات، ويدير المسؤولون المنصة. تختار بين العميل والمشغل أثناء onboarding؛ يُعيَّن دور المسؤول من قِبل مديري المنصة ولا يمكن اختياره ذاتياً.

يحدث التحقق من الأدوار على جانب الخادم في كل طلب، لا في واجهة المستخدم. تحت API، يُقيَّد الوصول إلى قاعدة البيانات إضافياً بسياسات row-level security، بحيث لا تتحول حتى ثغرة في نقطة نهاية إلى وصول مجاني لصفوف حسابات أخرى.

مفاتيح API

تمنح مفاتيح API البرامج النصية والخوادم وصولاً دون تسجيل دخول من المتصفح. تنشئها وتلغيها في /dashboard/settings؛ تحمل المفاتيح البادئة ayr_live_ وتُرسَل كـ Authorization Bearer header. يتصرف المفتاح بدور وصلاحيات الحساب الذي أنشأه، لذا فإن تسرب مفتاح سيئ تماماً كتسرب كلمة مرور.

• أبقِ المفاتيح على جانب الخادم. لا مكان لها في JavaScript على جانب العميل، أو تطبيقات الجوال، أو المستودعات العامة.
• استخدم مفتاحاً واحداً لكل تكامل. عندما يتسرب شيء، تريد إلغاء مستهلك واحد، لا الجميع.
• دوّر دون توقف: أنشئ المفتاح البديل أولاً، انشره، ثم ألغِ المفتاح القديم في /dashboard/settings.
• ألغِ فوراً عند أي شك. إنشاء مفتاح جديد يستغرق ثوانٍ؛ يمكن لمهاجم بمفتاح صالح فعل أي شيء يستطيع حسابك فعله.

ضمانات أثناء التحكم المباشر

التحكم المباشر مرتبط بـ session lease. لا يقبل الروبوت الأوامر إلا وهو ضمن جلسة ACTIVE واحدة بالضبط، وفقط من المشغل الحائز على تلك الجلسة؛ يُوسَم الروبوت نفسه بـ IN_SESSION لكل من عداه. يمكن لمشغل واحد الاحتفاظ بحد أقصى جلسة واحدة ACTIVE أو PAUSED في وقت واحد، ما يستبعد أن يتحكم شخص واحد اسمياً بذراعين في آن واحد.

يوفّر cockpit زر توقف طارئ يوقف الذراع فوراً، ويوقف إيقاف الجلسة مؤقتاً أو إنهاؤها تدفق الأوامر بأكمله. علاوة على ذلك، تراقب المنصة نشاط المشغل: بعد فترة بلا مدخلات يُرسَل تحذير عدم نشاط، وإن بقي المشغل غير نشط تتوقف الجلسة تلقائياً. هذا يحمي الجانبين، العميل من دفع مقابل وقت خامل، والروبوت من البقاء في حالة غير متحكَّم بها مع session lease نشط.

سجل التدقيق

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

إضافة إلى الجلسات، تُسجَّل إجراءات المنصة المهمة في سجل تدقيق مع id المستخدم المُنفِّذ، والإجراء، والمورد المتأثر، والبيانات الوصفية. تغييرات الملف الشخصي، والمعاملات المتعلقة بالدفع، وإجراءات المسؤولين، جميعها تترك سجلات. تُكتَب سجلات التدقيق بواسطة المنصة ولا يمكن تعديلها عبر أي واجهة تواجه المستخدم.

التشفير وحماية البيانات

كل حركة المرور من وإلى المنصة مشفَّرة أثناء النقل بـ TLS، بما في ذلك بث الفيديو وإشارات التحكم. على مستوى البيانات، تقيّد سياسات row-level security الوصول إلى قاعدة البيانات لكل حساب. بيانات الدفع هي الحد الأوضح على الإطلاق: يتولى Stripe وحده التعامل مع البطاقات والبيانات المصرفية ولا تلمس أبداً خوادم AY-Robots.

الإبلاغ عن ثغرة

إن وجدت مشكلة أمنية، أبلغ عنها بمسؤولية عبر صفحة /security أو نموذج /contact باستخدام فئة Bug Report. اذكر ما وجدته، وأين، وكيفية إعادة إنتاجه؛ لا تصل إلى بيانات مستخدمين آخرين تتجاوز الحد الأدنى اللازم لإثبات المشكلة، ولا تنشر التفاصيل قبل أن تُتاح لنا فرصة معقولة لإصلاحها. نقرأ كل بلاغ.

الأسئلة الشائعة