בעיית ה'מי רואה מה': הוספת הרשאות משתמשים לאפליקציה שבניתם עם בינה מלאכותית

הרגע שבו האפליקציה שבניתם עם בינה מלאכותית מפסיקה להיות רק שלכם הוא הרגע שבו הרשאות הופכות לבעיה אמיתית. עד אז, כל עמוד מציג הכול. כל רשימה מציגה כל שורה. כל כפתור עובד לכולם. זו אפליקציית שחקן-יחיד שמעמידה פנים שהיא רב-משתתפים.

ואז אתם מוסיפים את חבר הצוות הראשון שלכם, או את הלקוח הראשון שלכם, או את בודק הבטא הראשון שלכם — והוא רואה דבר שהוא לא צריך לראות. אולי זו המשכורת של חבר הצוות שלו. אולי זו טיוטה שלא הייתה מוכנה. אולי אלה הגדרות הניהול, שנחשפו בטעות.

זו בעיית ה**“מי רואה מה”**, וזה הדבר היחיד הכי גדול שבונים לא-טכניים טועים בו כששוחררים פרויקט של כלי לבניית אפליקציות עם בינה מלאכותית. החדשות הטובות: אתם לא צריכים להפוך למומחי אבטחה כדי לפתור את זה. אתם רק צריכים דרך ברורה לדבר על זה עם הכלי שלכם.

למה האפליקציה שבניתם עם בינה מלאכותית מתחילה מתירנית

כשאתם מתארים אפליקציה לכלי — “אני רוצה CRM שבו אני יכול להוסיף לקוחות והערות” — הכלי מבצע אופטימיזציה לדבר אחד: לגרום לזה לעבוד עבור האדם שמתאר אותו. אפליקציית ברירת המחדל היא “כל מי שמחובר יכול לראות הכול”. זה בסדר לכלי אישי. זה אסון ברגע שמשתמש שני מופיע.

זה לא באג בכלי. זו התוצאה הטבעית של כך שלא אמרתם לו מי מורשה לראות מה. לכלי אין מושג שרשימת הלקוחות שלכם רגישה, או ש”הערות” אולי מכילות דברים שאתם לא רוצים שלקוחות יראו. אתם צריכים לומר את זה.

שלוש השאלות לשאול לפני הוספת משתמש שני

לפני שאתם מזמינים מישהו, שאלו את עצמכם שלושה דברים. כתבו את התשובות — תזינו אותן לכלי בצעד הבא.

1. מי התפקידים?

לא האנשים — הקטגוריות. לרוב האפליקציות יש איפשהו בין שניים לארבעה. עבור פורטל פרילנסר: “אני” ו”לקוח”. עבור כלי פנימי: “מנהל מערכת”, “מנהל”, “חבר צוות”. עבור אפליקציית קהילה: “מנחה”, “חבר”, “אורח”. התנגדו לדחף לעבור מעל ארבעה תפקידים מוקדם. כל תפקיד מכפיל את הכללים שאתם צריכים לעקוב אחריהם.

2. עבור כל תפקיד, מה הוא יכול לראות?

עברו על כל עמוד באפליקציה שלכם, בראש. עבור כל אחד, שאלו: האם לקוח צריך לראות את העמוד הזה בכלל? האם הוא צריך לראות את כל הנתונים עליו, או רק את שלו? האם הוא צריך לראות את העמוד אבל עם שדות מסוימים מוסתרים?

הדפוס הכי פשוט: בעלים רואים הכול; כל השאר רואים רק את מה שניתנה להם גישה אליו במפורש. זה עובד ל-80% מהאפליקציות בלי הרבה התאמה אישית.

3. עבור כל תפקיד, מה הוא יכול לעשות?

אותו תרגיל, אבל לכפתורים ולפעולות. האם חבר יכול למחוק פרויקט? האם לקוח יכול לערוך את הפרופיל שלו אבל לא את התוכנית שלו? האם מנהל יכול להזמין אנשים חדשים? רוב הבונים הלא-טכניים שוכחים את הצעד הזה לגמרי ובסוף יש להם אפליקציות שבהן כל משתמש מחובר יכול למחוק את כל מסד הנתונים בלחיצת כפתור אחת.

לדבר עם הכלי שלכם על הרשאות

ברגע שיש לכם תשובות, ההנחיה לכלי כותבת את עצמה. היא נראית כך:

תעדכן את האפליקציה הזו כדי לתמוך בשני תפקידים: בעלים ולקוח.

בעלים יכולים לראות את כל הלקוחות, כל הפרויקטים, וכל החשבוניות. בעלים יכולים ליצור, לערוך, ולמחוק כל דבר.

לקוחות יכולים לראות רק את הפרויקטים שלהם ואת החשבוניות שלהם. הם לא יכולים לראות את רשימת הלקוחות, את עמוד הצוות, או את עמוד ההגדרות. הם יכולים לצפות בפרויקטים שלהם אבל לא לערוך אותם. הם יכולים לצפות ולשלם את החשבוניות שלהם.

כשלקוח מחובר, תסתיר את קישורי הניווט להגדרות ולצוות. אם לקוח מנסה לבקר בעמודים האלה דרך כתובת URL, תפנה אותו ללוח הבקרה שלו.

שלושה דברים חשובים בהנחיה הזו:

היו ספציפיים לפי עמוד ופעולה. “לקוחות יכולים לראות את הפרויקטים שלהם” מעורפל. “לקוחות יכולים לצפות אבל לא לערוך את הפרויקטים שלהם בעמוד /projects” זה משהו שכלי באמת יכול ליישם.
אמרו מה קורה לניווט. הסתרת הקישור אינה אותו דבר כמו חסימת העמוד. אתם רוצים את שניהם.
כסו את המקרה של הקלדת URL. אחרת משתמש סקרן יכול להדביק /admin לשורת הדפדפן שלו ולהיכנס ישר.

ארבע הטעויות שאני רואה כל שבוע

אחרי שצפיתי בהרבה בונים משחררים את האפליקציה הראשונה שלהם עם ריבוי משתמשים, אותן טעויות מופיעות:

להסתיר את הכפתור אינו להסתיר את הנתונים. אם אתם אומרים לכלי “תסתיר את כפתור המחיקה ללקוחות”, הכפתור נעלם מהמסך. אבל פעולת המחיקה הבסיסית עדיין עובדת אם מישהו מבין איך לקרוא לה. התיקון: אמרו לכלי גם “תדחה בקשות מחיקה מחשבונות שאינם בעלים בצד השרת”. אם הכלי לא יודע מה “צד השרת” אומר באפליקציה שלכם, בקשו ממנו “לחסום את הפעולה בצד השרת, לא רק להסתיר את הכפתור”.

תפקיד אחד לשתי עבודות. אנשים מבלבלים בין “האנשים שמשלמים” ל”האנשים שמשתמשים באפליקציה”. לקוח שמשלם לכם על עבודה ועובד-לקוח שמשתמש בלוח הבקרה שבניתם לאותו לקוח אינם אותו תפקיד. אם תערבבו אותם, תבלו את החודש הבא בטלאי כללים חד-פעמיים. שני תפקידים. תמיד.

לתת למשתמשים להזמין משתמשים מהיום הראשון. מפתה להוסיף “הזמן חבר צוות” מיד. אל תעשו זאת. עבור 10 המשתמשים הראשונים שלכם, הזמינו אותם בעצמכם, ידנית, מלוח ניהול שרק אתם יכולים לראות. הזמנות בשירות עצמי הן קטגוריה שלמה של כללי הרשאות (מי יכול להזמין את מי? איזה תפקיד מקבלים המוזמנים? האם הם יכולים להזמין אחרים?). חכו עד שתצטרכו את זה באמת.

לסמוך על מה שהכלי אומר בלי לבדוק. כלים יגידו לכם, בביטחון, שההרשאות מוגדרות. אולי הן כן. אולי הן לא. תמיד בדקו על ידי התחברות כמשתמש שאינו בעלים וניסיון לעשות דברים רעים: ללחוץ על כפתורי מחיקה, להדביק כתובות URL של ניהול, לערוך שדות שלא אמורים להיות מסוגלים לערוך. אם משהו עובד שלא אמור, בקשו מהכלי לתקן את זה באופן ספציפי.

רשימת בדיקה מהירה לפני שאתם מזמינים מישהו

לפני שאתם שולחים את ההזמנה הראשונה למשתמש שני, עברו על זה:

אני יכול למנות את התפקידים באפליקציה שלי על יד אחת.
עבור כל תפקיד, אני יודע אילו עמודים הוא צריך לראות ואילו לא.
התחברתי כמשתמש שאינו בעלים ואישרתי שהעמודים הלא נכונים מוסתרים.
ניסיתי להדביק כתובת URL של ניהול בדפדפן כמשתמש שאינו בעלים ונחסמתי.
ניסיתי ללחוץ על כפתורי מחיקה או עריכה שאמורים להיות מחוץ לתחום ונחסמתי.
אם משהו משתבש, יש לי דרך להסיר גישה של משתמש מהר.

אם אחת מהנקודות האלה לא עוברת, זו השיחה הבאה עם הכלי — לפני שאתם שולחים את ההזמנה, לא אחרי.

שינוי הלך הרוח האחד שעוזר

לבנות הרשאות לאפליקציה רב-משתמשים זה בעיקר עניין של לדמיין שאתם גרסה קצת חטטנית של המשתמש הכי גרוע שלכם. לא זדוני — פשוט סקרן. הוא ילחץ על דברים. הוא ידביק כתובות URL. הוא ינסה לראות מה יש בעמוד “ההגדרות” שהוא שם לב אליו בצילום המסך שלכם.

התפקיד שלכם — והתפקיד של הכלי שלכם — הוא לוודא שכשהוא מסתכל, התשובה עקבית: או שהוא יכול לראות את זה כי אלה הנתונים שלו, או שהוא לא יכול לראות את זה כי אלה לא. בלי קצוות. בלי עמודי ניהול שנחשפו בטעות. בלי “שכחתי שהעמוד הזה קיים”.

רוב הבונים לא חושבים על הרשאות עד שמשהו מביך קורה. החדשות הטובות: לבלות 20 דקות במחשבה על תפקידים לפני שאתם משחררים חוסך לכם את 20 השעות של לתקן את זה אחר כך, פלוס את המייל שאתם לא רוצים לכתוב ללקוח שראה את הדבר הלא נכון.

בונים משהו עם צד רב-משתמשים? בפעם הבאה שאתם מתיישבים עם הכלי שלכם, התחילו את הסשן במניית התפקידים באפליקציה שלכם בקול. זה ההרגל הכי קל של חמש דקות לבנות, והוא יתפוס את רוב הטעויות הכי גרועות לפני שהן קורות.