Skip to main content
تطلب خدمة web (وحدة login-register) اختبار reCAPTCHA v2 (غير المرئي) عند تسجيل الدخول بالبريد الإلكتروني، وتسجيل الدخول عبر LDAP، والتسجيل، وإعادة تعيين كلمة المرور. أنشئ المفتاح واقرأ ما يفعله كل إعداد في reCAPTCHA؛ أما هذه الصفحة فتشرح وضعه في Kubernetes.

الإعداد

1

مفتاح الموقع في الـ ConfigMap

مفتاح الموقع عام: تعرضه كل صفحة تسجيل دخول.
2

المفتاح السري ومفتاح سجل الأجهزة في الـ Secret

اضبط المفتاحين معًا: فمع وجود مفتاح الموقع دون المفتاح السري، يفشل كل تحقق ولا يستطيع أحد تسجيل الدخول بكلمة مرور أو التسجيل أو إعادة تعيين كلمة المرور. يجب أن يتكوّن DEVICE_HISTORY_SECRET من 64 حرفًا ست عشريًا؛ ولا تولّده الحاوية.
3

طبّق التغييرات وأعد التشغيل

ثم تحقّق من أن كل Pod يصل إلى نقطة النهاية. تتوقف الـ Pods بعد نحو ثانية واحدة لكل محاولة اتصال، ويفشل تسجيل الدخول الذي يتعذّر إجراء التحقق له مع ظهور خطأ:

عدة نسخ متماثلة

يجب أن تشترك جميع النسخ المتماثلة في DEVICE_HISTORY_SECRET، وهو ما يتحقق عندما يكون في الـ Secret. ومع اختلاف القيم، سيُطلب من المتصفح الذي اجتاز الاختبار على نسخة متماثلة اختبار captcha مجددًا على نسخة أخرى. تُحتسب حدود المعدّل في Redis عبر جميع النسخ المتماثلة.

الاختبار على Kubernetes

مقابل نسخة محاكاة (mock) لنقطة التحقق الخاصة بـ Google (موثوقة عبر NODE_EXTRA_CA_CERTS من overleaf-certs)، على Kubernetes 1.37، نجحت اختباراتنا الشاملة لـ reCAPTCHA ‏(13 حالة): على نسخة متماثلة واحدة، رُفض كل من تسجيل الدخول والتسجيل وإعادة تعيين كلمة المرور دون captcha أو مع captcha فاشل، وقُبل مع captcha ناجح، وسمح سجل الأجهزة المستند إلى DEVICE_HISTORY_SECRET للمتصفح بتخطي captcha، وCAPTCHA_TRUSTED_USERS؛ وعلى ثلاث نسخ متماثلة خلف HAProxy، تسجيل الدخول عبر LDAP مع captcha.
آخر تعديل في ٢ نوفمبر ٢٠٢٦