🚀 AllWDbook — من الفكرة إلى الإطلاق
AllWDbook Build Journal
كيف يعمل نظام الوصول في AllWDbook بدون فرض إنشاء حساب
لماذا اختير نظام AWD-KEY بدل فرض التسجيل بالبريد وكلمة المرور، وكيف يمكن للمستخدم استعادة الوصول على جهاز جديد.
عند بناء منصة رقمية، يبدو تسجيل الدخول في البداية وكأنه الحل الطبيعي لكل شيء: نطلب من الزائر إنشاء حساب، نحفظ بياناته، ثم نربط جميع المزايا بهذا الحساب.
لكن أثناء تطوير AllWDbook ظهر سؤال أكثر أهمية: هل يحتاج ناشر يريد تجربة حاسبة أو أداة بحث أو مصمم غلاف إلى إنشاء حساب قبل أن يعرف أصلًا إن كانت المنصة مفيدة له؟
كان الجواب بالنسبة لنا: لا.
من هنا بدأ بناء نظام وصول مختلف. يستطيع الزائر استخدام الأدوات المجانية دون المرور بإجراء تسجيل إجباري، بينما تعتمد المزايا المدفوعة على نظام AWD-KEY والاستعادة. وفي الجهة المقابلة، تم فصل صلاحيات الإدارة عن تجربة المستخدم العادي بحيث لا يكفي مجرد معرفة رابط لوحة الإدارة للوصول إلى بياناتها.
خلال تطوير هذا النظام ظهرت أيضًا تفاصيل صغيرة لكنها مهمة، مثل زر الإدارة الذي يجب ألا يظهر إلا للمسؤول الحقيقي، ومكانه على شاشة الهاتف حتى لا يحجب هوية الموقع.
هذه المقالة توثق لماذا اخترنا هذا الأسلوب، وكيف فصلنا بين سهولة دخول المستخدم وبين الصلاحيات الحساسة الخاصة بإدارة AllWDbook.
لماذا لم نرد فرض إنشاء حساب على كل زائر؟
منصة AllWDbook مبنية أساسًا حول أدوات عملية. قد يدخل المستخدم لأنه يريد حساب أرباح كتاب، البحث عن كلمات مفتاحية، دراسة Micro-Niche أو تجربة أداة مرتبطة بالغلاف.
في هذه الحالة، وضع شاشة تسجيل كاملة أمامه قبل أن يصل إلى الأداة يضيف خطوة لا تقدم له قيمة مباشرة. هو لم يأتِ أولًا لإدارة ملف شخصي؛ جاء لتنفيذ مهمة.
لذلك كان من المهم أن تكون التجربة الأولى قصيرة: افتح الموقع، اختر الأداة، وابدأ العمل ضمن الحدود المجانية المتاحة.
هذا القرار لا يعني أن الحسابات عديمة الفائدة، بل يعني أن إنشاء الحساب يجب أن يخدم حاجة حقيقية، لا أن يصبح حاجزًا افتراضيًا أمام كل زائر.
جلسة الزائر يمكن أن تعمل دون حساب تقليدي
لكي تتمكن المنصة من إدارة حدود الاستخدام والحالة التقنية للمستخدم، ما زالت تحتاج إلى طريقة لتمييز الجلسة الحالية. لكن هذا لا يتطلب بالضرورة بريدًا وكلمة مرور.
يمكن إنشاء جلسة مجهولة في الخلفية تسمح للنظام بالتعامل مع استخدام الأدوات دون مطالبة الزائر بإنشاء حساب تقليدي.
من منظور المستخدم تبقى التجربة بسيطة. هو يدخل إلى الموقع ويستعمل الأدوات، بينما تتولى المنصة إدارة التفاصيل التقنية التي تحتاجها في الخلفية.
هذه النقطة مهمة لأن هناك فرقًا بين احتياج التطبيق إلى Session تقنية وبين إجبار كل مستخدم على بناء هوية كاملة داخل المنصة.
AWD-KEY يفصل حق الوصول عن عملية تسجيل الدخول
بالنسبة إلى الوصول المدفوع، احتجنا إلى طريقة تضمن أن المستخدم يستطيع الاحتفاظ بحقه حتى إذا تغير الجهاز أو المتصفح.
هنا جاء دور AWD-KEY. بدل جعل الوصول مرتبطًا فقط بجلسة تسجيل دخول على جهاز معين، يصبح للمستخدم رمز يمكن استخدامه لاستعادة الخطة وتفعيلها وفق قواعد النظام.
هذا النموذج يجعل فكرة الملكية أكثر وضوحًا: ما حصل عليه المستخدم بعد التفعيل لا يعتمد فقط على بقاء Cookie أو Session في متصفحه.
كما أنه يسمح ببناء مسار استعادة مستقل عن تجربة تسجيل الدخول التقليدية، وهو أمر مهم لمنصة تريد إبقاء الاستخدام اليومي بسيطًا.
الاستعادة جزء من تصميم الوصول وليست ميزة إضافية
أي نظام وصول لا يكتمل إذا كان يعمل فقط على الجهاز الأول. المستخدم قد يغير هاتفه، يحذف بيانات المتصفح أو يحتاج إلى استعمال جهاز آخر.
لهذا تم التعامل مع الاستعادة كجزء أساسي من النظام، وليس كحل طارئ يضاف بعد حدوث المشكلة.
يمكن استعادة الوصول من خلال AWD-KEY، كما توجد آليات حماية واستعادة إضافية للحالات المؤهلة، مع الحفاظ على عدم كشف معلومات حساسة بصورة غير ضرورية.
الهدف من ذلك أن تكون تجربة الاستخدام السهلة في البداية متوازنة مع إمكانية المحافظة على حق المستخدم لاحقًا.
دخول الإدارة مشكلة مختلفة تمامًا
سهولة الدخول المناسبة للزائر لا تعني أن لوحة الإدارة يجب أن تتبع القواعد نفسها.
الإدارة تستطيع التعامل مع بيانات أكثر حساسية مثل الإحصاءات، مفاتيح الوصول، الأجهزة والخطط. لذلك لا يمكن أن تعتمد الحماية على مجرد إخفاء رابط Admin أو وضع زر لا يراه الزائر.
في AllWDbook يتم التحقق من جلسة المسؤول ثم التحقق على الخادم من أن المستخدم يملك صلاحية إدارية فعالة قبل إعادة البيانات الإدارية.
وهذا يعني أن معرفة رابط /admin وحدها لا تمنح صلاحيات. الحماية الحقيقية موجودة في طبقة الخادم، وليس في شكل الواجهة فقط.
زر Admin يظهر فقط عندما تكون الصلاحية موجودة
أثناء العمل على لوحة الإدارة احتجنا إلى طريقة سريعة للوصول إليها من داخل الموقع دون إضافة رابط إداري واضح لجميع الزوار.
تم استخدام زر Admin مخصص يتحقق أولًا من الجلسة الحالية ثم يختبر صلاحية الإدارة. إذا لم يكن المستخدم مسؤولًا، لا يظهر الزر أصلًا.
بهذا تصبح الواجهة مختلفة حسب السياق: الزائر يرى AllWDbook كمنصة أدوات، بينما المسؤول الذي تم التحقق منه يرى مدخلًا إضافيًا إلى لوحة الإدارة.
لكن مرة أخرى، إخفاء الزر ليس وسيلة الحماية الأساسية. حتى لو حاول شخص فتح المسار الإداري مباشرة، تبقى واجهات API مسؤولة عن رفض الطلبات غير المصرح بها.
تفصيل صغير: زر الإدارة على شاشة الهاتف
بعد إضافة زر الإدارة ظهرت مشكلة بصرية بسيطة لكنها واضحة على الهاتف. وضع الزر في أعلى الواجهة جعله يقترب من شعار AllWDbook واسم المنصة.
هذه ليست مشكلة أمنية، لكنها مثال جيد على أن إضافة وظيفة جديدة قد تؤثر في واجهة مستقرة من مكان لم يكن متوقعًا.
تم تعديل موضع الزر أكثر من مرة حتى يبقى في أعلى الشاشة وفي المنتصف مع ترك مساحة مناسبة لعناصر الهيدر.
مثل هذه التعديلات الصغيرة مهمة في مشروع Mobile-First، لأن بضعة بكسلات قد تصنع فرقًا واضحًا على شاشة ضيقة.
المبدأ الأهم: لا تخلط تجربة الزائر بصلاحيات الإدارة
أحد الدروس المهمة من هذا العمل هو أن كلمة "دخول" قد تشير إلى احتياجات مختلفة تمامًا.
الزائر يحتاج إلى أقل قدر ممكن من الاحتكاك حتى يستعمل الأداة. صاحب الخطة يحتاج إلى طريقة موثوقة لاستعادة حقه. أما المسؤول فيحتاج إلى تحقق صارم قبل الوصول إلى بيانات الإدارة.
محاولة استخدام مسار واحد لهذه الحالات الثلاث تجعل النظام أكثر تعقيدًا وقد تجعل الواجهة مربكة للمستخدم.
فصل هذه المسؤوليات جعل البنية أوضح: استخدام مجاني بسيط، وصول مدفوع قابل للاستعادة، وإدارة محمية بصلاحيات مستقلة.
ما الذي تعلمناه من بناء نظام الوصول؟
أفضل نظام تسجيل ليس بالضرورة النظام الذي يطلب أكبر كمية من المعلومات. النظام الجيد يطلب فقط ما يحتاجه السياق.
في AllWDbook كان المطلوب من الزائر أن يبدأ استخدام الأدوات بسرعة، ومن المستخدم المدفوع أن يحتفظ بحقه، ومن المسؤول أن يدخل إلى منطقة محمية بصورة صارمة.
هذه الاحتياجات الثلاث لا تتعارض إذا تم فصلها بصورة صحيحة.
النتيجة هي منصة تستطيع تقديم تجربة سهلة للمستخدم العادي دون التضحية بالحماية المطلوبة للعمليات الإدارية الحساسة.