مسئلهٔ «چه کسی چه چیزی را میبیند»: افزودن دسترسیهای کاربری به اپ ساختهشده با هوش مصنوعیتان
بیشتر اپهای ساختهشده با هوش مصنوعی با یک کاربر شروع میشوند: خودتان. روزی که نفر دوم را اضافه میکنید، به دسترسیها نیاز دارید — و بیشتر مردم این را اشتباه انجام میدهند. اینجا میگوییم چطور بدون تبدیل شدن به یک متخصص امنیت به آن فکر کنید.
لحظهای که اپ ساختهشده با هوش مصنوعیتان دیگر فقط برای شما نیست، همان لحظهای است که دسترسیها به یک مشکل واقعی تبدیل میشوند. تا پیش از آن، هر صفحه همه چیز را نشان میدهد. هر فهرست هر ردیف را نشان میدهد. هر دکمه برای همه کار میکند. این یک اپ تکنفره است که وانمود میکند چندنفره است.
بعد اولین همتیمی، یا اولین مشتری، یا اولین آزمونگر بتایتان را اضافه میکنید — و آنها چیزی را میبینند که نباید ببینند. شاید حقوقِ همتیمیشان باشد. شاید پیشنویسی که آماده نبود. شاید تنظیمات مدیریتی که اتفاقی لو رفتهاند.
این همان مسئلهٔ «چه کسی چه چیزی را میبیند» است، و بزرگترین چیزی است که سازندگان غیرفنی هنگام منتشر کردن یک پروژهٔ اپساز هوش مصنوعی اشتباه انجام میدهند. خبر خوب: لازم نیست متخصص امنیت شوید تا حلش کنید. فقط به یک راه روشن برای حرف زدن دربارهٔ آن با اپساز هوش مصنوعیتان نیاز دارید.
چرا اپ ساختهشده با هوش مصنوعیتان از همان آغاز همهچیزبازِ همه است
وقتی اپی را برای یک اپساز هوش مصنوعی توصیف میکنید — «یک CRM میخواهم که بتوانم مشتری و یادداشت اضافه کنم» — اپساز برای یک چیز بهینه میکند: اینکه برای همان کسی که توصیفش میکند کار کند. اپ پیشفرض این است: «هر کسی که وارد شده میتواند همه چیز را ببیند». برای یک ابزار شخصی خوب است. همان لحظهای که نفر دوم پیدایش شود یک فاجعه است.
این یک باگ در اپساز هوش مصنوعی نیست. نتیجهٔ طبیعی این است که شما به آن نگفتهاید چه کسی مجاز است چه چیزی را ببیند. اپساز هیچ ایدهای ندارد که فهرست مشتریهایتان حساس است، یا اینکه «یادداشتها» ممکن است چیزهایی داشته باشد که نمیخواهید مشتریها ببینند. باید بگویید.
سه پرسشی که پیش از افزودن کاربر دوم باید بپرسید
پیش از آنکه کسی را دعوت کنید، سه چیز از خودتان بپرسید. پاسخها را بنویسید — در گام بعد آنها را به اپساز هوش مصنوعیتان میدهید.
۱. نقشها چه هستند؟
نه آدمها — دستهها. بیشتر اپها جایی بین دو تا چهار نقش دارند. برای یک پورتال فریلنسر: «من» و «مشتری». برای یک ابزار داخلی: «مدیر کل»، «مدیر»، «عضو تیم». برای یک اپ جامعهمحور: «ناظر»، «عضو»، «مهمان». از وسوسهٔ گذشتن از چهار نقش در همان آغاز پرهیز کنید. هر نقش، قواعدی را که باید پیگیری کنید دو برابر میکند.
۲. هر نقش چه چیزی را میتواند ببیند؟
در ذهنتان از تمام صفحههای اپتان بگذرید. برای هرکدام بپرسید: آیا یک مشتری باید اصلاً این صفحه را ببیند؟ آیا باید همهٔ دادههای آن را ببیند، یا فقط دادههای خودش را؟ آیا باید صفحه را ببیند اما با بعضی فیلدهای پنهان؟
سادهترین الگو: مالکان همه چیز را میبینند؛ بقیه فقط چیزی را میبینند که صریحاً به آنها دسترسی داده شده. این برای ۸۰٪ اپها بدون شخصیسازی زیاد جواب میدهد.
۳. هر نقش چه کاری را میتواند انجام دهد؟
همان تمرین، اما برای دکمهها و اقدامها. آیا یک عضو میتواند پروژهای را حذف کند؟ آیا یک مشتری میتواند پروفایلش را ویرایش کند اما نه پلنش را؟ آیا یک مدیر میتواند افراد جدید دعوت کند؟ بیشتر سازندگان غیرفنی این گام را کاملاً فراموش میکنند و در نهایت اپهایی میسازند که در آنها هر کاربرِ واردشده میتواند با یک کلیک دکمه کل پایگاه داده را حذف کند.
حرف زدن با اپساز هوش مصنوعیتان دربارهٔ دسترسیها
همین که پاسخها را داشتید، دستورِ اپساز هوش مصنوعیتان خودش نوشته میشود. شکلش این است:
این اپ را بهروزرسانی کن تا از دو نقش پشتیبانی کند: مالک و مشتری.
مالکان میتوانند همهٔ مشتریها، همهٔ پروژهها و همهٔ صورتحسابها را ببینند. مالکان میتوانند هر چیزی را بسازند، ویرایش کنند و حذف کنند.
مشتریها فقط میتوانند پروژههای خودشان و صورتحسابهای خودشان را ببینند. آنها نمیتوانند فهرست مشتریها، صفحهٔ تیم، یا صفحهٔ تنظیمات را ببینند. میتوانند پروژههایشان را ببینند اما نمیتوانند ویرایششان کنند. میتوانند صورتحسابهای خودشان را ببینند و پرداخت کنند.
وقتی یک مشتری وارد شده است، لینکهای ناوبری به تنظیمات و تیم را پنهان کن. اگر یک مشتری تلاش کند با URL به آن صفحهها برود، او را به داشبوردش هدایت کن.
سه چیز در آن دستور مهم است:
- با ذکر صفحه و اقدام دقیق باشید. «مشتریها میتوانند پروژههایشان را ببینند» مبهم است. «مشتریها میتوانند پروژههای خودشان را در صفحهٔ /projects ببینند اما ویرایش نکنند» چیزی است که یک اپساز هوش مصنوعی واقعاً میتواند پیادهاش کند.
- بگویید بر سر ناوبری چه میآید. پنهان کردن لینک با مسدود کردن صفحه یکی نیست. هر دو را میخواهید.
- حالتِ تایپکردنِ URL را پوشش دهید. وگرنه یک کاربر کنجکاو میتواند
/adminرا در نوار مرورگرش جایگذاری کند و راست وارد شود.
چهار اشتباهی که هر هفته میبینم
پس از تماشای ساختنِ اولین اپ چندکاربرهٔ خیلی از سازندگان، همان اشتباهها ظاهر میشوند:
پنهان کردن دکمه، پنهان کردن داده نیست. اگر به اپساز هوش مصنوعیتان بگویید «دکمهٔ حذف را برای مشتریها پنهان کن»، دکمه از صفحه ناپدید میشود. اما عملیات حذفِ زیرین هنوز کار میکند اگر کسی بفهمد چطور فراخوانیاش کند. راهحل: همچنین به اپساز بگویید «درخواستهای حذف از حسابهای غیرمالک را در backend رد کن». اگر اپساز نمیداند «backend» در اپ شما چه معنایی دارد، از آن بخواهید «اقدام را سمت سرور مسدود کن، نه فقط دکمه را پنهان کن».
یک نقش برای دو کار. مردم «کسانی که پول میدهند» را با «کسانی که از اپ استفاده میکنند» اشتباه میگیرند. مشتریای که برای کار به شما پول میدهد و کارمندِ مشتریای که از داشبوردی که برای آن مشتری ساختید استفاده میکند یک نقش نیستند. اگر قاطیشان کنید، ماه بعدتان را صرف وصلهٔ قواعد تکموردی خواهید کرد. دو نقش. همیشه.
اجازهٔ دعوت کاربر به کاربرها از همان روز اول. وسوسهانگیز است که فوراً «یک همتیمی دعوت کن» را اضافه کنید. نکنید. برای ۱۰ کاربر اولتان، خودتان، با دست، از یک پنل مدیریتی که فقط خودتان میبینیدش دعوتشان کنید. دعوتهای خودخدماتی یک دستهٔ کاملِ قواعد دسترسی است (چه کسی میتواند چه کسی را دعوت کند؟ دعوتشدهها چه نقشی میگیرند؟ آیا میتوانند بقیه را دعوت کنند؟). صبر کنید تا واقعاً به آن نیاز داشته باشید.
اعتماد به آنچه اپساز هوش مصنوعی میگوید بدون بررسی. اپسازهای هوش مصنوعی با اطمینان به شما میگویند که دسترسیها راهاندازی شدهاند. شاید شده باشند. شاید نشده باشند. همیشه با وارد شدن بهعنوان یک غیرمالک و تلاش برای انجام کارهای بد آزمایش کنید: روی دکمههای حذف کلیک کنید، URLهای مدیریتی را جایگذاری کنید، فیلدهایی را که نباید بتوانید ویرایش کنید. اگر هر چیزی که نباید کار میکند کار کرد، از اپساز بخواهید مشخصاً درستش کند.
یک فهرست بازبینی سریع پیش از دعوت هر کسی
پیش از آنکه آن اولین دعوت را به کاربر دوم بفرستید، این را مرور کنید:
- میتوانم نقشهای اپم را با انگشتان یک دست بشمارم.
- برای هر نقش میدانم کدام صفحهها را باید ببینند و کدام را نباید.
- بهعنوان یک غیرمالک وارد شدهام و تأیید کردهام که صفحههای اشتباه پنهاناند.
- تلاش کردهام بهعنوان یک غیرمالک یک URL مدیریتی را در مرورگر جایگذاری کنم و مسدود شدهام.
- تلاش کردهام روی دکمههای حذف یا ویرایشی که باید ممنوع باشند کلیک کنم و مسدود شدهام.
- اگر چیزی اشتباه پیش برود، راهی برای حذف سریع دسترسی یک کاربر دارم.
اگر هرکدام از این موارد رد نشد، آن همان گفتوگوی بعدی با اپساز هوش مصنوعیتان است — پیش از فرستادن دعوت، نه بعدش.
یک تغییر ذهنی که کمک میکند
ساختن دسترسیها برای یک اپ چندکاربره بیشتر دربارهٔ این است که تصور کنید نسخهای کمی فضولِ بدرفتارترین کاربرتان هستید. نه بدخواه — فقط کنجکاو. روی چیزها کلیک میکنند. URLها را جایگذاری میکنند. تلاش میکنند ببینند روی صفحهٔ «تنظیمات» که در اسکرینشاتتان دیدهاند چه چیزی هست.
کار شما — و کار اپساز هوش مصنوعیتان — این است که مطمئن شوید وقتی نگاه میکنند، پاسخ یکدست است: یا میتوانند ببینندش چون دادهٔ خودشان است، یا نمیتوانند ببینندش چون نیست. بدون لبه. بدون صفحههای مدیریتیِ اتفاقی لورفته. بدون «فراموش کرده بودم آن صفحه وجود دارد».
بیشتر سازندگان تا وقتی اتفاق شرمآوری نیفتد به دسترسیها فکر نمیکنند. خبر خوب: صرف ۲۰ دقیقه فکر کردن دربارهٔ نقشها پیش از انتشار، شما را از ۲۰ ساعتِ درست کردنش بعداً نجات میدهد، بهعلاوهٔ آن ایمیلی که نمیخواهید به مشتریای که چیز اشتباه را دیده بنویسید.
دارید چیزی با یک جنبهٔ چندکاربره میسازید؟ دفعهٔ بعد که با اپساز هوش مصنوعیتان نشستید، جلسه را با بلندبلند گفتنِ نقشهای اپتان شروع کنید. این آسانترین عادتِ پنجدقیقهای است که میتوانید بسازید، و بیشتر بدترین اشتباهها را پیش از وقوع دستگیر میکند.