لقد قمت مؤخرًا بتنفيذ SIWE لمشروع وأردت أن أشارك ما تعلمته لأن العملية في الواقع بسيطة جدًا بمجرد فهم المفهوم الأساسي.

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

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

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

في النهاية، استخدمت Next.js لتنفيذ كامل الواجهة والخلفية لأنك تستطيع التعامل مع الاثنين في مشروع واحد. بدأت بحزم npm مثل Ant Design Web3 و Wagmi - فهي تتولى الكثير من الأعمال الشاقة. يمكنك تثبيت الاعتمادات الأساسية عبر npm بأمر واحد، مما يوفر الكثير من وقت الإعداد.

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

شيء لاحظته - استخدام عقد RPC الافتراضي يجعل عملية التحقق تستغرق حوالي 30 ثانية، وهو أمر قاسٍ لتجربة المستخدم. الانتقال إلى خدمة عقد مخصصة (استخدمت ZAN) قلل ذلك بشكل كبير. بالتأكيد يستحق التحسين إذا كنت ستنشر التطبيق في الإنتاج.

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

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