ניהול הרשאות בצורה חכמה
-
@yossiz
כשאתה שואל שאלות זה די מייאש
כי אם אתה לא מצאת איך אני ימצא?
אבל חיפוש בגוגל הביא לי כמה תוצאות
אולי זה מה שאתה מחפש?
https://en.wikipedia.org/wiki/Role-based_access_control
https://en.wikipedia.org/wiki/Attribute-based_access_control
https://zupzup.org/casbin-http-role-auth/ -
@yossiz אתה מדבר על גישה מעניינת שלא שמעתי עליה, ממתי מנהלים הרשאות דרך הדאטבייס? תמיד ידעתי שניהול ההרשאות מסור בידי השרת, מה גורם לך לנטות מהדרך הבטוחה הזו?
עריכה
אני מבין שמפריע לך שאתה כותב הרבה קוד, אם ככה לא מכיר פיתרון, רק ליצור כלים יותר גנריים שיבנו את השאילתות (מורכב), או לפצל את ה API לפי רמות הרשאה ולעצור את הבקשה בטרם תגיע לשאילתה (תוספת קוד) או לשלב את שני הדרכים
אבל קשה לי להאמין שאפשר לנהל רמות הרשאה דרך המסד נתונים, לא נראה לי שהוא בנוי לדברים כאלה, בגלל שאין לו דרך לדעת מי מבקש את השאילתה, מבחינתו המתשאל הוא היוזר שהתחבר למסד, מאיפה הוא יכול לדעת מי הסשן שביקש את השאילתה? -
עשיתי את זה בעבר בצורה דומה, אבל הניהול היה בקוד ע"י תישאול הDB
שם בעיקר היה קריאה כתיבה מחיקה וכו
ולא לפי עמודה (ברוב המקרים)קצת קשה (ואולי גם מסוכן) לעשות את ההרשאות ברמת הDB
באקסס (ה"י ) זה היה אפשרי ברמת הטבלה וכו, וגם בSQL SERVER ונראה לי בשאר זה אפשרי.
אבל אני יודע שהגישה בשנים האחרונות השתנתה בנושא הזה.שים לב שאם אתה משתמש בהרשאות ברמת הDB, אתה חייב שכל משתמש שלך יש לו גם משתמש ברמת הDB, וממילא הDB יודע מה ההרשאות שלו, (ללא קשר לסשן) - ז"אא אתה צריך בשליחה לשלוח גם את השם משתמש והסיסמא של הDB
היה על זה דיון בעבר הרחוק, ואני זוכר דווקא ש @dovid צידד בעניין (היה משהו עם הרשאות של בנק נראה לי)
תספר כמובן בסוף מה עשית,
ואם אפשר, אז גם מה הDB שלך? -
אני חושב שהרשאות ה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