ניהול הרשאות בצורה חכמה
-
אני חושב שהרשאות הDB עשויות כקיר הגנה אחרון שהוא בעיקר נגד טעויות פיתוח (טעויות לוגיות וכדומה) וגם סתם הגנה מפני המפתחים, לא מפני המשתמשים. הרשאות הDB הם גסות יחסית, אי אפשר לוודא כל מיני כללים קטנים, איזה תנאים מותר, איזה מאפיינים לקריאה ואיזה לכתיבה וכו'.
למשתמש אסור שתהיה לעולם הרשאה לDB, וגם גישה דרך אפליקציה נחשבת גישה ישירה אם אתה לא מממש לוגיקה שמחליטה למי מה ואיך לאפשר לפני כל פעולה. ממילא הרשאות הDB שהם תופסת עדיף שיהיו רזות ככל האפשר כדי לא כל פעם לתחזק בשני מקומות, מאידך הם נצרכים לפי כללי הספר כקו הגנה נוסף. -
תודה לכולכם על התגובות המחכימות
לקחתם אותי רציני מדי... אני יודע שאין כזה פתרון קיים בא' מה-DB המסורתיים. לא חלמתי להשתמש בהרשאות ברמת DB עם אחד מה-DB-ים הנפוצים.
שאלתי היתה יותר ברמה תיאורטית.
האם מה שקיים הוא באמת הפתרון המיטבי? האם זו באמת המהלך הכי טוב, לבדוק את ה-role של מבקש הגישה ולבנות שאילתה שמתאים ל-role לפי הלוגיקה הייחודית של אפליקציה זו, כאשר המפריד היחיד בין בקשת המשתמש למשאב שהוא ביקש הוא הקוד השברירי שבונה את השאילתה?
זה מרגיש קצת לא אלגנטי ומקום מועד לקשיים בתחזוק, שגיאות לוגיקה וסתם באגים.
גם יוצא שהלוגיקה של בקרת גישה מפוזר בהמון מקומות בקוד, וגם גורם להרבה כפילות של קוד.דמיינו לעצמכם שהרשאות גישה במערכת ההפעלה היו עובדים כך,
זה היה גורם לבלאגן שלם.מכיון שזה תחום שכל אפליקציה עסקית מגודל כלשהו ואילך נתקל בו, הייתי מצפה שיהיה איזה פריימוורק שיטפל בתחום.
-
@nigun אמר בניהול הרשאות בצורה חכמה:
תודה רבה!
קישור זה הוביל אותי לספרייה שבנוייה בדיוק לטפל בזה
https://casbin.orgעריכה: אחרי העיון זה לא עושה מה שרציתי. זה רק פריימוורק למידול ושמירה של הרשאות, (מצאתי כבר ספרייות אחרות שעושים את זה ואני משתמש באחד כזה (CASL)), אבל זה לא אוכף את ההרשאות בפועל על המשאבים, זה עדיין נשאר בידי המתכנת. אבל זו בהחלט ספרייה מעניינת.
-
@yossiz אמר בניהול הרשאות בצורה חכמה:
גם יוצא שהלוגיקה של בקרת גישה מפוזר בהמון מקומות בקוד, וגם גורם להרבה כפילות של קוד.
- ככל ויש תכנות מונחה עצמים אז אין כ"כ הרבה מקומות בקוד שצריך לתחזק משהו כיון שמעדכנים אובייקט אחד עם כל הנתונים הרלוונטיים ואח"כ ניגשים איתו ולא צריך לגשת לד"ב שוב. לדוגמא יוצר יוזר עם כל ההרשאות שלו ואח"כ עם ההרשאות ניגש לפונקציות שלהם יש לו גישה (או לקבוצות שהוא נמצא, שגם הם מופיעים כמתודה בתוך האובייקט הזה).
- לגבי עצם הגישה לפונקציות, (אני לא יודע אם זוהי הדרך הנכונה ביותר, אבל ככה אני עושה), ניתן לעשות שער API עם רשימת פונקציות (מסודרות בטבלה), ועוד טבלה של הרשאות ליוזר לפי id פונקציה. ככה תמיד הגישה היא רק מתוך הרשימה של הפונקציות שאושרו ליוזר.
-
@yossiz תתאר מה יש בCASL או תתאר בגדול איך יעבוד הפרימוורק אותו אתה שואף שיהיה.
נניח יש JSON ושמה מגדירים רשימת משתמשים ועל כל משתמש טבלאות מורשות פעולות מורשות מאפיינים וכו'.
כעת מכל מקום באפליקציה, קל לגרום שתהיה שגיאה במקרה של חריגה (וזה כבר דבר טוב שלא חשבתי עליו והבאת לתודעתי)
אבל איך ייתכן שלא יצטרכו לכתוב בכל מקום שאילתה מתאימה לrole המתאים? גם את זה ניתן להגדיר דקלרטיבית? קשה לי לדמיין, תתאר לי מה אתה חושב. -
@dovid אני מצרף pseudo code.
זה מבוסס באופן רופף על התחביר של CASL.
תחביר התנאים של CASL מבוסס על תחביר mongo.ROLES.JSON
{ "user": { "rules": [ { "action": "view", "subject": "project", "fields": {"$not": {"$in": ["privateField1", "xxxx", "superSecret"] } }", "conditions": { "ownerId": "$myId" } ] }, "manager": { "rules": [ { "action": "view", "subject": "project", "fields": ["*"], "deny": false, "conditions" { "$or": [{ "orgId": "$myOrgId"}, {"sharedWith": { $elemMatch: "$myOrgId" } }] } ] }
projectController
class Project { list (filter) { let query = permsToQuery(user, 'view', 'Project'); query.where.push(filter); db.projects.list(query); } } function permsToQuery(user, action, subject) { let abilities = buildAbilities(user.roles); return superMagicLibraryFunctionConvertAbilitiesToSQLWhereCondition(abilities, action, subject); }
-
@dovid
לא ציינתי, אבל יש אפשרות ב-CASL להפוך את ההרשאות בצורה אוטומטית לשאילתת Sequelize גם כן. (תחביר התנאים של Sequlize גם דומה מאוד לתנאי mongo)
כבר כתבתי קוד שעובד על פי זה.
אבל נטשתי את זה כי זה לא נתמך בצורה טובה.https://stalniy.github.io/casl/v4/en/advanced/ability-to-database-query