بناء نموذج تسجيل آمن: التحقق من المدخلات في الواجهة والخادم

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

ابدأ بعقد واضح للحقول المقبولة

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

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

اجعل تحقق الواجهة مساعدًا واضحًا للمستخدم

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

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

تحقق على الخادم قبل تنفيذ منطق التسجيل

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

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

عالج البريد والأسماء دون إفساد القيم

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

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

صمم سياسة كلمة المرور ومسار تخزينها معًا

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

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

امنع التكرار عند قاعدة البيانات وأكد ملكية البريد

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

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

اعرض الأخطاء دون كشف الحسابات أو إخفاء الأعطال

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

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

اختبر الحدود وطبقات الحماية المحيطة بالنموذج

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

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

أسئلة شائعة

هل يكفي استخدام مكتبة تحقق واحدة مشتركة بين الواجهة والخادم؟

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

لماذا يُقبل البريد في النموذج ثم لا تصل رسالة التأكيد؟

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

هل ينبغي إزالة الرموز الخاصة من كل المدخلات لمنع الهجمات؟

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

كيف أتعامل مع الضغط المتكرر على زر إنشاء الحساب؟

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