مشكلة "من يرى ماذا": إضافة صلاحيات المستخدمين إلى تطبيقك المبني بالذكاء الاصطناعي
معظم التطبيقات المبنية بالذكاء الاصطناعي تبدأ بمستخدم واحد: أنت. في اليوم الذي تضيف فيه شخصاً ثانياً، تحتاج إلى صلاحيات — ومعظم الناس يخطئون في هذا. إليك كيف تفكّر بالأمر دون أن تصبح خبير أمان.
اللحظة التي يكفّ فيها تطبيقك المبني بالذكاء الاصطناعي عن أن يكون لك وحدك هي اللحظة التي تصبح فيها الصلاحيات مشكلة حقيقية. حتى تلك اللحظة، كانت كل صفحة تعرض كل شيء. وكل قائمة تعرض كل صفّ. وكل زرّ يعمل للجميع. إنه تطبيق فردي يتظاهر بأنه متعدّد اللاعبين.
ثم تضيف أول زميل لك، أو أول عميل، أو أول مختبِر تجريبي — فيرون شيئاً لا ينبغي أن يروه. ربما يكون راتب زميلهم. ربما تكون مسوّدة لم تكن جاهزة. ربما تكون إعدادات المسؤول، مكشوفة بالخطأ.
هذه هي مشكلة “من يرى ماذا”، وهي أكبر شيء يخطئ فيه الصنّاع غير التقنيين حين يُطلقون مشروعاً مبنياً بمنصّة بناء التطبيقات بالذكاء الاصطناعي. والخبر الجيّد: لست بحاجة إلى أن تصبح خبير أمان لحلّها. أنت بحاجة فقط إلى طريقة واضحة للحديث عنها مع منصّة البناء.
لماذا يبدأ تطبيقك المبني بالذكاء الاصطناعي متساهلاً
حين تصف تطبيقاً لمنصّة بناء بالذكاء الاصطناعي — “أريد نظام إدارة علاقات عملاء أستطيع فيه إضافة العملاء والملاحظات” — تحسّن المنصّة لأجل شيء واحد: جعله يعمل للشخص الذي يصفه. والتطبيق الافتراضي هو “كل من سجّل دخوله يستطيع رؤية كل شيء”. هذا جيّد لأداة شخصية. وكارثة لحظة ظهور مستخدم ثانٍ.
هذا ليس خطأً في منصّة بناء التطبيقات بالذكاء الاصطناعي. بل هو النتيجة الطبيعية لعدم إخبارك إيّاها من المسموح له برؤية ماذا. ليس لدى المنصّة أدنى فكرة أن قائمة عملائك حسّاسة، أو أن “الملاحظات” قد تحتوي على أشياء لا تريد أن يراها العملاء. عليك أن تقول ذلك.
الأسئلة الثلاثة التي تطرحها قبل إضافة مستخدم ثانٍ
قبل أن تدعو أي أحد، اسأل نفسك ثلاثة أشياء. اكتب الإجابات — ستغذّيها لمنصّة البناء في الخطوة التالية.
1. ما هي الأدوار؟
ليس الأشخاص — بل الفئات. معظم التطبيقات لديها ما بين اثنين وأربعة أدوار. لبوّابة مستقلّ: “أنا” و”العميل”. لأداة داخلية: “مسؤول”، و”مدير”، و”عضو فريق”. لتطبيق مجتمعي: “مشرف”، و”عضو”، و”ضيف”. قاوِم الرغبة في تجاوز أربعة أدوار مبكّراً. كل دور يُضاعف القواعد التي عليك تتبّعها.
2. لكل دور، ماذا يستطيع أن يرى؟
استعرض كل صفحة في تطبيقك، ذهنياً. لكل واحدة، اسأل: هل ينبغي للعميل أن يرى هذه الصفحة أصلاً؟ هل ينبغي أن يرى كل البيانات عليها، أم بياناته فقط؟ هل ينبغي أن يرى الصفحة لكن مع إخفاء بعض الحقول؟
أبسط نمط: المالكون يرون كل شيء؛ والجميع الآخرون يرون فقط ما مُنحوا الوصول إليه صراحةً. ينجح هذا لـ 80% من التطبيقات دون تخصيص كثير.
3. لكل دور، ماذا يستطيع أن يفعل؟
التمرين نفسه، لكن للأزرار والإجراءات. هل يستطيع العضو حذف مشروع؟ هل يستطيع العميل تعديل ملفّه الشخصي لكن ليس خطّته؟ هل يستطيع المدير دعوة أشخاص جدد؟ معظم الصنّاع غير التقنيين ينسون هذه الخطوة كلّياً وينتهي بهم الأمر بتطبيقات يستطيع فيها أي مستخدم سجّل دخوله أن يحذف قاعدة البيانات بأكملها بنقرة زرّ واحدة.
الحديث مع منصّة البناء عن الصلاحيات
حالما تصبح لديك الإجابات، يكتب الطلب الموجّه لمنصّة البناء نفسه. يبدو هكذا:
حدّث هذا التطبيق ليدعم دورين: المالك والعميل.
يستطيع المالكون رؤية كل العملاء، وكل المشاريع، وكل الفواتير. يستطيع المالكون إنشاء أي شيء وتعديله وحذفه.
يستطيع العملاء رؤية مشاريعهم وفواتيرهم فقط. لا يستطيعون رؤية قائمة العملاء، أو صفحة الفريق، أو صفحة الإعدادات. يستطيعون عرض مشاريعهم لكن لا يستطيعون تعديلها. يستطيعون عرض فواتيرهم ودفعها.
حين يسجّل العميل دخوله، أخفِ روابط التنقّل إلى الإعدادات والفريق. وإن حاول العميل زيارة تلك الصفحات عبر الرابط، فأعِد توجيهه إلى لوحة تحكّمه.
ثلاثة أشياء تهمّ في ذلك الطلب:
- كن محدّداً بحسب الصفحة والإجراء. عبارة “يستطيع العملاء رؤية مشاريعهم” غامضة. أمّا “يستطيع العملاء عرض مشاريعهم لكن ليس تعديلها على صفحة /projects” فهو شيء تستطيع منصّة البناء تنفيذه فعلاً.
- قُل ماذا يحدث للتنقّل. إخفاء الرابط ليس كحظر الصفحة. أنت تريد الأمرين.
- غطِّ حالة كتابة الرابط. وإلّا استطاع مستخدم فضولي أن يلصق
/adminفي شريط متصفّحه ويدخل مباشرة.
الأخطاء الأربعة التي أراها كل أسبوع
بعد مراقبة كثير من الصنّاع وهم يُطلقون أول تطبيق متعدّد المستخدمين، تظهر الأخطاء نفسها:
إخفاء الزرّ ليس إخفاء البيانات. إن طلبت من منصّة البناء “إخفاء زرّ الحذف عن العملاء”، فسيختفي الزرّ من الشاشة. لكن عملية الحذف الكامنة لا تزال تعمل إن اكتشف أحدهم كيف يستدعيها. الحلّ: اطلب أيضاً من المنصّة “رفض طلبات الحذف من الحسابات غير المالكة على الخادم”. إن لم تعرف المنصّة ماذا يعني “الخادم” في تطبيقك، فاطلب منها “حظر الإجراء من جانب الخادم، لا مجرّد إخفاء الزرّ”.
دور واحد لوظيفتين. يخلط الناس بين “من يدفعون” و”من يستخدمون التطبيق”. العميل الذي يدفع لك مقابل العمل، والموظّف-العميل الذي يستخدم لوحة التحكّم التي بنيتها لذلك العميل، ليسا الدور نفسه. إن مزجتهما، فستقضي الشهر القادم في ترقيع قواعد فردية. دوران. دائماً.
السماح للمستخدمين بدعوة مستخدمين من اليوم الأول. من المغري إضافة “ادعُ زميلاً” فوراً. لا تفعل. في أول 10 مستخدمين لك، ادعُهم بنفسك، يدوياً، من لوحة مسؤول لا يراها سواك. الدعوات الذاتية فئة كاملة من قواعد الصلاحيات (من يستطيع دعوة من؟ ما الدور الذي يحصل عليه المدعوون؟ هل يستطيعون دعوة آخرين؟). انتظر حتى تحتاج إليها فعلاً.
الثقة بما تقوله منصّة البناء دون تحقّق. ستخبرك منصّات البناء، بثقة، أن الصلاحيات مُهيّأة. قد تكون كذلك. وقد لا تكون. تحقّق دائماً بتسجيل الدخول كمستخدم غير مالك ومحاولة فعل أشياء سيئة: انقر أزرار الحذف، ألصِق روابط المسؤول، عدّل حقولاً لا ينبغي أن تستطيع تعديلها. إن نجح أي شيء لا ينبغي أن ينجح، فاطلب من المنصّة إصلاحه تحديداً.
قائمة فحص سريعة قبل أن تدعو أي أحد
قبل أن ترسل تلك الدعوة الأولى لمستخدم ثانٍ، راجع هذه:
- أستطيع تعداد الأدوار في تطبيقي على أصابع يد واحدة.
- لكل دور، أعرف أيّ الصفحات ينبغي أن يراها وأيّها لا ينبغي.
- سجّلت الدخول كمستخدم غير مالك وأكّدت أن الصفحات الخاطئة مخفيّة.
- حاولت لصق رابط مسؤول في المتصفّح كمستخدم غير مالك وجرى حظري.
- حاولت النقر على أزرار الحذف أو التعديل التي ينبغي أن تكون ممنوعة وجرى حظري.
- إن حدث خطأ ما، فلديّ وسيلة لإزالة وصول مستخدم بسرعة.
إن لم تجتَز أيٌّ من تلك النقاط، فتلك هي المحادثة التالية مع منصّة البناء — قبل أن ترسل الدعوة، لا بعدها.
التحوّل الذهني الوحيد الذي يساعد
بناء الصلاحيات لتطبيق متعدّد المستخدمين يدور في معظمه حول أن تتخيّل أنك نسخة فضولية قليلاً من أسوأ مستخدميك سلوكاً. ليس خبيثاً — فقط فضولياً. سينقرون على الأشياء. سيلصقون الروابط. سيحاولون رؤية ما على صفحة “الإعدادات” التي لاحظوها في لقطة شاشتك.
مهمّتك — ومهمّة منصّة البناء — هي التأكّد من أنه حين ينظرون، تكون الإجابة متّسقة: إمّا أنهم يستطيعون رؤيته لأنه بياناتهم، أو لا يستطيعون رؤيته لأنه ليس كذلك. لا حواف. لا صفحات مسؤول مكشوفة بالخطأ. لا “نسيت أن تلك الصفحة موجودة”.
معظم الصنّاع لا يفكّرون في الصلاحيات حتى يحدث شيء محرج. والخبر الجيّد: قضاء 20 دقيقة في التفكير بالأدوار قبل الإطلاق يوفّر عليك 20 ساعة من إصلاحه لاحقاً، إضافةً إلى البريد الإلكتروني الذي لا تريد كتابته للعميل الذي رأى الشيء الخاطئ.
هل تبني شيئاً له جانب متعدّد المستخدمين؟ في المرّة القادمة التي تجلس فيها مع منصّة بناء التطبيقات بالذكاء الاصطناعي، ابدأ الجلسة بتعداد الأدوار في تطبيقك بصوت مسموع. إنها أسهل عادة من خمس دقائق يمكنك اكتسابها، وستلتقط معظم أسوأ الأخطاء قبل أن تحدث.