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

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

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

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

لقد كنت أختبر التنفيذ الفعلي باستخدام Next.js و Ant Design Web3. الإعداد أنظف مما توقعت. تثبت الاعتمادات، تربط مزود Wagmi مع إعداد SIWE الخاص بك، وفجأة - لديك اتصال بالمحفظة وتوقيع مدمجين. الأجزاء الرئيسية هي نقطة نهاية Nonce (تولد وتخزن قيمة عشوائية مرتبطة بعنوان المستخدم) ونقطة التحقق (تتحقق من التوقيع، تتطابق مع Nonce، ثم تصدر JWT).

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

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