كيف تضيف تسجيل الدخول إلى تطبيقك: كلمات المرور وروابط الدخول وGoogle والأدوار

لإضافة تسجيل الدخول إلى تطبيقك، اختر طريقة: البريد الإلكتروني وكلمة المرور، أو روابط الدخول السحرية (رابط دخول لمرة واحدة يُرسل بالبريد الإلكتروني)، أو "تسجيل الدخول بحساب Google"، ونفّذها بمكتبة مصادقة مُجرَّبة أو بمزوّد مستضاف بدلاً من كتابتها من الصفر. ثم قرر ما يحق لكل نوع من المستخدمين فعله (الأدوار)، وطبّق ذلك على الخادم في كل صفحة وكل طلب API. ويجب أن تكون الجلسات مؤمّنة بملفات تعريف ارتباط آمنة، وأن تنتهي صلاحيتها، وأن تنتهي بشكل صحيح عند تسجيل الخروج.

يشرح هذا الدليل كل خيار والتفاصيل التي تفصل بين تسجيل دخول يعمل وتسجيل دخول آمن. وللمفاهيم التي يقوم عليها، راجع ما هي المصادقة.

قرر أولاً: هل تحتاج إلى تسجيل دخول أصلاً؟

تسجيل الدخول يضيف احتكاكاً ومسؤولية. تحتاج إليه عندما:

• يملك المستخدمون بيانات خاصة (حجوزاتهم، ومستنداتهم، وفواتيرهم)
• يستطيع المستخدمون تغيير أشياء سيراها الآخرون
• تتقاضى ثمن الوصول
• يحتاج أشخاص مختلفون إلى صلاحيات مختلفة (المالك مقابل الموظف مقابل العميل)

قد لا تحتاج إليه في موقع تسويقي، أو دليل عام، أو نموذج يرسل لك بريداً إلكترونياً فقط. قائمة الانتظار لا تحتاج إلى حسابات؛ يكفي حقل بريد إلكتروني.

طرق تسجيل الدخول الأربع الشائعة

كثير من التطبيقات تجمع طريقتين: تسجيل الدخول بحساب Google مع روابط بريد سحرية، وهو ثنائي شائع يغطي معظم الناس دون تخزين أي كلمة مرور.

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

إذا قدّمت كلمات المرور، فهذه الأمور لا تقبل التفاوض:

• جزّئ كلمات المرور بخوارزمية بطيئة مخصصة لذلك. توصي إرشادات OWASP لتخزين كلمات المرور بخوارزمية Argon2id، مع scrypt أو bcrypt أو PBKDF2 كبدائل. لا تخزّن كلمات المرور نصاً عادياً أبداً، ولا باستخدام تجزئة عامة وسريعة.
• إعادة تعيين كلمة المرور تستخدم رابطاً عشوائياً لمرة واحدة ينتهي صلاحيته، يُرسل إلى البريد الإلكتروني المؤكد.
• لا تكشف أي البريد الإلكتروني له حساب. عبارة "إذا كان هذا البريد مسجلاً لدينا، فقد أرسلنا رابط إعادة التعيين" أفضل من "لم نجد حساباً".
• حدّد معدل المحاولات لتسجيل الدخول وإعادة التعيين حتى تبطئ تخمين كلمات المرور.
• اسمح بكلمات مرور طويلة ومديري كلمات المرور، وتجنّب قواعد تفرض تشكيلات غريبة من الرموز.

روابط الدخول السحرية ورموز لمرة واحدة

رابط الدخول السحري هو رابط تسجيل دخول يُرسل بالبريد الإلكتروني إلى المستخدم، والنقر عليه يسجّل دخوله. والرمز لمرة واحدة هو الفكرة نفسها، لكن يُكتب بدلاً من أن يُنقر.

• تنتهي صلاحية الروابط والرموز بسرعة، ولا تعمل إلا مرة واحدة.
• ينبغي أن يسجّل الرابط دخول المستخدم على الجهاز الذي نقر فيه، ويجب ألا يبقى الرمز في السجلات أو في أدوات التحليلات.
• تحتاج إلى إرسال بريد موثوق؛ راجع كيف ترسل رسائل البريد الإلكتروني من تطبيقك. اختبر مع Gmail وOutlook، وتحقق من مجلدات الرسائل غير المرغوب فيها.

تسجيل الدخول بحساب Google (وغيره من مزوّدي OAuth)

يستخدم "تسجيل الدخول بحساب Google" بروتوكولي OAuth وOpenID Connect: تؤكد Google هوية المستخدم، وتخبر تطبيقك ببريده الإلكتروني واسمه. والإعداد، اعتباراً من سبتمبر 2026، يتم في قسم Google Auth Platform داخل Google Cloud Console:

1. أنشئ مشروعاً أو اختره، واملأ صفحة Branding، وهي ما يراه المستخدمون في شاشة الموافقة (اسم التطبيق، وبريد الدعم، والشعار).
2. في صفحة Clients، أنشئ عميلاً من نوع "Web application".
3. أضف authorized JavaScript origins وredirect URIs، وهي العناوين الدقيقة التي يعمل عليها تطبيقك وتعيد Google المستخدمين إليها بعد تسجيل الدخول.
4. احفظ معرّف العميل والسرّ الخاص به في أسرار تطبيقك.

أمور تحدث كثيراً بحسب وثائق OAuth لدى Google:

• redirect_uri_mismatch: يجب أن يتطابق عنوان إعادة التوجيه تماماً، بما في ذلك http مقابل https، والحروف الكبيرة والصغيرة، وأي شرطة مائلة في النهاية. أضف واحداً لعنوان المعاينة وآخر لنطاقك الحي.
• يُشترط HTTPS: يجب أن تستخدم عناوين إعادة التوجيه بروتوكول HTTPS، إلا localhost أثناء التطوير.
• يجب فحص معامل state عند العودة لحماية الطلب من تزوير الطلبات عبر المواقع (CSRF). المكتبات الجيدة تفعل ذلك عنك.

إذا طلبت معلومات الدخول الأساسية فقط (الاسم والبريد والملف الشخصي)، تقول Google إن التحقق من التطبيق ليس إلزامياً. أما طلب الوصول إلى Gmail أو Drive أو Calendar لدى المستخدمين فأمر مختلف ويتطلب التحقق.

تبنيه بنفسك أم تستخدم مزوّداً؟

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

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

تخبرك طريقة تسجيل الدخول بـمن هو الشخص، بينما تحدد الصلاحيات ما يستطيع فعله. أبقِه بسيطاً في البداية:

القواعد التي تهم أكثر من أسماء الأدوار:

• تحقّق على الخادم في كل مرة. إخفاء زر في الصفحة لا يمنع أحداً من استدعاء الـ API مباشرة.
• حصّر الوصول بالمالك. إذا طلب عضو "الحجز 123"، فلا يجب أن يحصل عليه إلا إذا كان حجزه.
• لا يستطيع المستخدمون ترقية أنفسهم. تجاهل حقول الأدوار القادمة من المتصفح عند تحديث الملف الشخصي.
• الافتراضي هو عدم الوصول. يجب أن تتطلب المسارات الجديدة تسجيل الدخول، إلا إذا قررت غير ذلك.

اختبر ذلك بحسابين: سجّل الدخول بأحدهما، وسجّل معرّف أحد السجلات، ثم سجّل الدخول بالآخر وحاول فتحه. تتضمن قائمة الأمان للتطبيقات المبنية بالذكاء الاصطناعي الاختبار الكامل.

أمان الجلسات

بعد تسجيل الدخول، يتذكر التطبيق المستخدم عبر جلسة، وغالباً ما تكون ملف تعريف ارتباط. وتوصي إرشادات OWASP لإدارة الجلسات بما يلي:

• ملفات تعريف ارتباط للجلسة مضبوطة بخاصية Secure (عبر HTTPS فقط) وHttpOnly (لا تقرؤها سكربتات الصفحة) وSameSite
• إصدار معرّف جلسة جديد عند تسجيل الدخول، وكذلك عند تغيّر الصلاحيات
• مهلة خمول، وعمر أقصى مطلق، يُفرضان على الخادم
• تسجيل خروج ينهي الجلسة على الخادم، لا يكتفي بحذف ملف الارتباط
• إبطال الجلسات عند تغيير المستخدم لكلمة مروره

تخزين رموز الدخول في localStorage في المتصفح شائع في الدروس التعليمية، لكنه يعرّضها لأي سكربت يعمل على الصفحة؛ وملفات تعريف الارتباط الآمنة هي الافتراضي الأفضل لتطبيقات الويب عادةً.

أمر يغطي الأساسيات

أضف حسابات مستخدمين إلى هذا التطبيق. يستطيع المستخدمون التسجيل وتسجيل الدخول بالبريد الإلكتروني وكلمة المرور، أو بحساب Google. استخدم [المكتبة أو المزوّد] بدلاً من كتابة كود مصادقة مخصص. جزّئ كلمات المرور بخوارزمية Argon2id أو bcrypt. أضف إعادة تعيين كلمة المرور عبر البريد الإلكتروني برابط لمرة واحدة ينتهي خلال ساعة. احفظ الجلسات في ملفات تعريف ارتباط آمنة وHttpOnly. احمِ /dashboard وكل مسارات /api بحيث لا يستخدمها إلا المستخدمون المسجّلون دخولهم، واجعل كل مستخدم يرى مشاريعه فقط. أضف دور "admin" يستطيع رؤية كل المستخدمين؛ ولا يصل إلى /admin إلا المشرفون، ويُتحقق من ذلك على الخادم.

ثم اختبر: سجّل حساباً، واخرج، وسجّل الدخول من جديد، وأعد تعيين كلمة المرور، وحاول فتح صفحة خاصة وأنت خارج الحساب، وحاول الوصول إلى سجل مستخدم آخر.

أخطاء شائعة في تسجيل الدخول المبني بالذكاء الاصطناعي

• الحماية في الصفحة فقط. الصفحة تعيد توجيه المستخدمين غير المسجّلين، لكن الـ API يعيد البيانات لأي أحد.
• أسرار في المتصفح. أسرار عميل OAuth ومفاتيح إدارة مزوّد المصادقة تنتمي إلى الخادم.
• خلط روابط المعاينة بالروابط الحية. عنوان إعادة التوجيه في Google أو رابط بريد إعادة التعيين يشير إلى المعاينة، فيتعطل تسجيل الدخول بعد النشر.
• عدم التحقق من البريد الإلكتروني. يستطيع أي شخص التسجيل بعنوان anyone@company.com. تحقق من البريد الإلكتروني قبل منح أي شيء مرتبط بهذا العنوان.
• اختبار المسار السعيد فقط. جرّب كلمات مرور خاطئة، وروابط منتهية الصلاحية، وحساباً ثانياً.

إضافة تسجيل الدخول في Mythex

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

1. اختر نهجاً، مثلاً البريد الإلكتروني وكلمة المرور المخزنة في قاعدة بياناتك، أو SDK لمزوّد مستضاف.
2. إذا كنت ستخزّن المستخدمين بنفسك، فالتطبيق يحتاج إلى قاعدة بيانات؛ اطلبها في المحادثة أو استخدم /database.
3. ضع مفاتيح المزوّد في أسرار المشروع (/secrets أو إعدادات المشروع).
4. استخدم أمراً مشابهاً للأمر أعلاه، ثم اختبر في المعاينة. ولتسجيل الدخول بحساب Google، أضف عناوين إعادة التوجيه لكل من المعاينة ورابطك المنشور.

راجع أضف تسجيل الدخول إلى تطبيقك في الوثائق. وإذا كنت تبني منتج SaaS مدفوعاً، فإن كيف تبني SaaS MVP يغطي الحسابات والفوترة معاً.

الأسئلة