كيفية جعل الروابط السحرية مع العقدة

يعد النظام الذي لا يحتوي على كلمة مرور والذي تم تقديمه بواسطة Slack كارتباط سحري بديلاً جيدًا حقًا لنظام مصادقة البريد الإلكتروني / كلمة المرور الأساسي لعدة أسباب. حتى إذا لم تتحكم في مستوى أمان تشفير كلمة المرور ، فأنت ترى أن موفر صندوق بريد المستخدم الخاص بك آمن بما فيه الكفاية وأن حقيقة إعادتهم إليك الرمز المميز الذي أرسلته للتو هو وسيلة كافية لمصادقتهم. وبهذه الطريقة ، يمكننا أن نرى هذا بمثابة مصادقة OAuth رخيصة (مثل Facebook) لا توفر لنا أي معلومات عن المستخدم.

الفرق بين oAuth والروابط السحرية

ماذا عن التنفيذ؟

باستخدام المخطط السابق ، نعلم أنه سيتعين علينا تنفيذ نقطتين فقط. واحد لتقديم طلب للحصول على مفتاح التوثيق واحد للحصول على المصادقة.

في نقطة نهاية المصادقة ، سنحتاج إلى 3 أشياء. الوصول إلى قاعدة البيانات الخاصة بنا للاستمرار في الحساب ، وإنشاء الرمز المميز وتوليد البريد. لإنشاء الرمز المميز ، سنستخدم نهج JSON Web Token. الميزة هي أنه يمكننا تضمين بعض المحتوى في الرمز المميز والتأكد من عدم تعديله.

سنقوم الآن بإنشاء رابط يحتوي على الرمز المميز في الاستعلام وإرسال هذا الرابط إلى مستخدمنا عن طريق البريد.

عندما ينقر المستخدم على هذا الرابط ، نحتاج إلى اعتراض الرمز المميز الذي تم تمريره كمعلمة استعلام ، وفك تشفير المحتوى ووضعه في سياق الطلب. لهذا الغرض ، يتعين علينا فقط استخدام برنامج وسيط سريع يسمى express-jwt.

الآن ، عندما ينقر المستخدم على الرابط ، سيكون لدينا معلوماته في السياق ويمكننا استخدامها فقط.

وهنا اكتمال دورة حياتنا. أصبح بإمكان مستخدمينا الآن المصادقة فقط باستخدام عنوان بريدهم الإلكتروني.

ماذا عن الأمن؟

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

أولها هو أن يكون لديك جدول قائمة سوداء للرمز الذي نريد الإلغاء. مزعج للغاية وضد مبدأ صنع الرموز JWT.

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

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

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

مثال سيكون لطيف!

الكود المصدري للمثال قيد التشغيل متاح على الرابط التالي.

المهتمين من خلال تقديم الطلب؟