يدعم Bedrud طرق مصادقة متعددة.

JWT (رموز ويب JSON)

يستخدم Bedrud JWT لإدارة الجلسات. عند تسجيل الدخول، يُرجع الخادم رمزين:

١. رمز الوصول: قصير الأمد (مثلاً ساعة واحدة). يُستخدم للوصول إلى نقاط نهاية API المحمية. ٢. رمز التحديث: طويل الأمد (مثلاً ٣٠ يومًا). يُستخدم للحصول على رمز وصول جديد دون تسجيل الدخول مرة أخرى.

تتحقق الخلفية من هذه الرموز في ملف internal/middleware/auth.go.

إدارة الرموز والأمان

١. استراتيجية زوج الرموز (التدوير)

يستخدم Bedrud استراتيجية تدوير رموز آمنة. عندما يُصادق المستخدم، يتلقى:

• رمز الوصول: مُوقَّع بـ HS256، يحتوي على معرّف المستخدم والاسم والصلاحيات. صالح لمدة قصيرة (يُهيَّأ عبر tokenDuration).
• رمز التحديث: رمز منفصل طويل الأمد.

التدوير: عندما ينتهي رمز الوصول، يُرسل العميل رمز التحديث إلى /api/auth/refresh. يُصدر الخادم بعد ذلك زوجًا جديدًا تمامًا من الرموز ويُحدّث رمز التحديث المخزّن في قاعدة البيانات. هذا يُقلل نافذة الفرصة حتى لو سُرق الرمز.

٢. إبطال الرموز (القائمة السوداء)

لدعم تسجيل الخروج الآمن، يُنفّذ Bedrud قائمة سوداء للرموز.

• عندما يسجّل المستخدم الخروج، يُضاف رمز التحديث الحالي إلى جدول blocked_refresh_tokens.
• قبل تحديث أي جلسة، يفحص الخادم هذا الجدول. إذا كان الرمز محظورًا، يُرفض الطلب فورًا.
• مهمة خلفية (المجدول) مُصممة لتنظيف هذه الرموز المحظورة بمجرد انتهاء صلاحيتها الطبيعية.

٣. بنية مطالبات JWT

تحمل الرموز بيانات وصفية تسمح للخلفية والواجهة الأمامية باتخاذ قرارات سريعة دون الوصول إلى قاعدة البيانات:

{
  "userId": "uuid-string",
  "email": "user@example.com",
  "name": "Display Name",
  "accesses": ["user", "admin"],
  "exp": 123456789,
  "iat": 123456780
}

طرق المصادقة

١. البريد الإلكتروني المحلي وكلمة المرور

• تُجزَّر كلمات المرور باستخدام bcrypt - لا تُخزَّن أبدًا كنص عادي.
• عند التسجيل، يُنشأ سجل مستخدم جديد في قاعدة البيانات.

٢. تسجيل الدخول الاجتماعي (OAuth2)

يستخدم Bedrud مكتبة Goth لدعم:

• Google
• GitHub
• Twitter

يمكنك تفعيل هذه بملء قسم auth: في ملف config.yaml بمعرّف العميل وسر API الخاصين بك.

٣. مفاتيح المرور (WebAuthn/FIDO2)

يدعم Bedrud المصادقة بدون كلمة مرور عبر معيار FIDO2 (WebAuthn).

• مراسم التسجيل: ١. البداية: يُنشئ الخادم تحدّيًا آمنًا تشفيريًا ويخزّنه في جلسة المستخدم. ٢. النهاية: المُصادِق الخاص بالعميل (مثلاً TouchID، YubiKey) يُوقّع التحدّي. يتحقق الخادم من الشهادة، يستخرج المفتاح العام، ويحفظه في جدول passkeys.
• مراسم المصادقة: ١. البداية: يُصدر الخادم تحدّيًا جديدًا. ٢. النهاية: يُوقّع العميل التحدّي بمفتاحه الخاص. يسترجع الخادم المفتاح العام من قاعدة البيانات، يتحقق من التوقيع، ويفحص عداد التوقيع.
• الأمان: مطابقة حقل Counter تمنع هجمات إعادة التشغيل. إذا لم يكن عداد المُصادِق أعلى من العداد المخزّن، يُرفض تسجيل الدخول.

٤. تسجيل الدخول كضيف

يسمح للمستخدمين بالانضمام إلى اجتماع فورًا بالاسم فقط. يُنشئ الخادم سجل مستخدم مؤقت بدور guest.

التحقق من البريد الإلكتروني

عند تعيين requireEmailVerification: true في الإعدادات، يتطلب التسجيل المحلي (غير OAuth) وتسجيل الدخول تأكيد البريد الإلكتروني:

• التسجيل ينشئ المستخدم ولكن يضبط EmailVerifiedAt على nil. لا يمكن للمستخدم تسجيل الدخول حتى يتم التحقق.
• تسجيل الدخول يُرجع 403 مع {"requiresVerification": true} للحسابات غير الموثقة.
• إعادة الإرسال عبر POST /api/auth/verify/resend — محدود بواسطة verificationEmailCooldownMins ومجموعة تحديد معدل منفصلة (authResendMaxRequests).
• التنظيف التلقائي يحذف الحسابات غير الموثقة بعد unverifiedAccountTTLHours (افتراضي 48 ساعة، 0 لتعطيل).
• تغيير البريد الإلكتروني يطلق عملية تحقق جديدة. يبقى المستخدم مسجل الدخول؛ يتم إصدار رمز جديد.

المستخدمون الضيوف مستثنون — ليس لديهم بريد إلكتروني.

إعادة تعيين كلمة المرور

عملية إعادة تعيين كلمة المرور (تتطلب SMTP):

1. POST /api/auth/forgot-password مع {"email": "..."} — يرسل الخادم رابط إعادة التعيين إلى البريد الإلكتروني
2. POST /api/auth/reset-password مع {"token": "...", "newPassword": "..."} — تعيين كلمة مرور جديدة

يتم التحكم في TTL رمز إعادة التعيين بواسطة resetTokenTTLHours (افتراضي ساعة واحدة). يشارك نقطة نهاية forgot-password مجموعة تحديد معدل المصادقة.

فترة التهدئة وتحديد المعدل

يستخدم Bedrud أربع مجموعات منفصلة لتحديد المعدل:

تعيين المجموعة على 0 = تعطيل. جميع الحدود لكل IP عن بُعد. الطلبات التي تتجاوز الحد تعيد 429 Too Many Requests مع رأس Retry-After.

التشغيل البيني و CORS

صُمم Bedrud ليكون متاحًا من أصول متعددة، مما هو ضروري للتطوير (خادم تطوير React) والإنتاج (نطاقات فرعية مختلفة).

• سياسة CORS: مُعرّفة في config.yaml. تدعم AllowCredentials: true، المطلوب لملفات تعريف الارتباط الخاصة بالجلسة المستخدمة في مراسم OAuth ومفاتيح المرور.
• الأصول المسموح بها: افتراضيًا، تسمح بنطاق الخادم نفسه و localhost:3000 (منفذ خادم تطوير React).

أدوار المستخدمين (التحكم في الوصول)

كل مستخدم لديه مصفوفة accesses يمكنها احتواء مستويات وصول متعددة في آنٍ واحد. مطالبات JWT تتضمن مصفوفة accesses الكاملة، مما يسمح للوسيط بالتحقق من الصلاحيات الدقيقة.

مستويات الوصول

هرم الأدوار

superadmin > admin > moderator > user > guest

يمكن لـ superadmin تنفيذ أي إجراء إشرافي في أي غرفة دون أن يُرقّى كمشرف غرفة. منشئو الغرف هم مشرفو غرفة تلقائياً ويمكنهم ترقية المشاركين إلى moderator.

تعيين الأدوار

تُدار الأدوار عبر قنوات متعددة:

• سطر الأوامر: bedrud user create (يُنشئ كمستخدم user)، bedrud user promote (يُضيف superadmin)، bedrud user demote (يُزيل superadmin)
• لوحة تحكم المشرف: صفحة تفاصيل المستخدم تحتوي على أزرار ترقية/خفض
• API المشرف: PUT /api/admin/users/:id/accesses مع مصفوفة accesses المطلوبة
• داخل الاجتماع: يمكن لمنشئ الغرفة ترقية المشاركين إلى moderator على مستوى الغرفة

ملاحظة: لا توجد نقطة نهاية API أو واجهة ويب لإنشاء أول superadmin. بعد التثبيت، يجب عليك استخدام سطر الأوامر (bedrud user create + bedrud user promote) لتهيئة وصول المشرف الأولي. هذا إجراء أمني متعمد.