כדי לוודא שרק משתמשים עם גישה לפריט יוכלו לראות את הפריט בתוך תוצאת חיפוש, עליכם להוסיף פריטים לאינדקס עם הרשימות של בקרת הגישה (ACL) שלהם מהמאגר הארגוני. צריך ליצור מודל של רשימות ה-ACL של המאגר לכלול את רשימות ה-ACL האלה בעת יצירת אינדקס של פריטים במאגר. מחבר התוכן ערכת ה-SDK מספקת קבוצה עשירה של שיטות ACL, חזקות מספיק כדי ליצור מודל של רשימות ה-ACL של ברוב המאגרים.
יצירת ACL
יצירת רשימת ACL היא תהליך דו-שלבי:
- לכתוב
Principal
באמצעות שיטות סטטיות ACL בכיתה. - שימוש ב
Acl.Builder
כדי ליצור את ה-ACL באמצעות חשבון המשתמש.
המשך המסמך הזה עוסק בכמה מושגים שצריך להכיר כדי ליצור מודל וליצור רשימות ACL, כמו ירושה או בלימה.
יצירת חשבון משתמש באמצעות מזהה חיצוני
ב-Google Cloud Search, משתמשים וקבוצות צריכים לטפל באימייל של Google
address. בזמן ההוספה לאינדקס של פריטי מאגר, ייתכן שמחברי התוכן לא יכללו את
כתובות אימייל. עם זאת, ה-SDK של מחבר התוכן מאפשר לך להשתמש בכל
מזהה חיצוני (מזהה שמעניק למשתמש או לקבוצה גישה לפריטים במאגר), במקום זאת
של כתובת אימייל, כדי להוסיף פריט לאינדקס. משתמשים ב
getUserPrincipal()
או
getGroupPrincpal()
כדי ליצור חשבונות משתמשים שמכילים מזהים חיצוניים. יש עוד כמה
שיטות סטטיות
ACL
הכיתה שמשמשת לבנייה
Principal
אובייקטים.
ירושה של ACL
ירושה של ACL מתייחסת להרשאה, לפריט ספציפי על סמך התוצאה של שילוב בין רשימות ה-ACL של הפריט רשימות ACL של שרשרת הירושה שלה. הכללים ששימשו לקבלת החלטה לגבי הרשאה תלויות במאגר ובמאפיינים של הפריט.
הגדרת הורשה
לכל פריט יכולים להיות חשבונות משתמשים מורשים ישירים וחשבונות משתמשים ישירים שנדחו,
מצוין באמצעות
setReaders()
וגם
setDeniedReaders()
שיטות. יש הרשאה ישירה
חשבון המשתמש הוא משתמש שמזוהה ב-ACL שמעניק לו גישה ישירה
פריט ספציפי. חשבון משתמש ישיר שנדחה הוא משתמש שמזוהה ב-ACL כלא
שיש להם גישה לפריט מסוים.
פריט יכול גם לרשת חשבונות משתמשים מורשים עקיפים וגם
חשבונות משתמשים שנדחו באופן עקיף באמצעות
setInheritFrom()
. חשבון משתמש מורשה עקיף הוא משתמש שבעזרת ירושה של ACL,
יש גישה עקיפה לפריט ספציפי. חשבון משתמש עקיף שנדחה הוא משתמש
ש, באמצעות ירושה של ACL, נדחתה הגישה לפריט ספציפי.
איור 1 מראה איך
ה-method setInheritFrom()
משמשת בירושה של חשבונות משתמשים מורשים עקיפים ועקיפים שנדחו.
![שרטוט של חיבורים בין פריטים](https://developers.google.cn/static/cloud-search/images/inherit-from-SDK.png?authuser=0000&hl=he)
setInheritFrom()
.בקרות הגישה האלה מיוצגות באיור 1:
- משתמש 1 הוא חשבון משתמש ישיר שמותר על ידי פריט א'.
- משתמש 2 הוא חשבון משתמש ישיר מורשה של פריט ב'.
- פריט ב' יורש את רשימת ה-ACL של פריט א'.
כללי הגישה מבוססים על בקרות הגישה:
- אין צורך לציין באופן מפורש את משתמש 1 כחשבון משתמש של פריט ב' חשבון משתמש מורשה עקיף של פריט ב'; הגישה עוברת בירושה כי משתמש 1 רשום כחשבון משתמש ישיר מורשה של פריט א' ופריט ב' יורש את רשימת ה-ACL שלו מפריט א'.
- משתמש 2 הוא לא חשבון משתמש עקיף של פריט א'.
הגדרת סוג הירושה
אם מגדירים ירושה באמצעות
setInheritFrom()
צריך להגדיר את סוג הירושה באמצעות
setInheritanceType()
. סוג הירושה קובע את האופן שבו
ACL משולבת עם רשימת ה-ACL של ההורה שלה. Acl.InheritanceType
כוללת שלושה סוגים של ירושה:
BOTH_PERMIT
- הגדרת סוג הירושה ל-BOTH_PERMIT
כדי להעניק גישה למשתמש לפריט רק כאשר גם ה-ACL של פריט הצאצא וגם ACL של הפריט שעבר בירושה כדי לאפשר למשתמש לגשת לפריט.CHILD_OVERRIDE
– הגדרת סוג הירושה ל-CHILD_OVERRIDE
כדי לאלץ את הילד או הילדה ה-ACL של הפריט יקבל קדימות על פני רשימת ה-ACL של פריט ההורה שעבר בירושה כאשר הם שיש התנגשות. כך, אם רשימת ה-ACL של פריט ההורה מונעת גישה למשתמש כקורא שנדחה, למשתמש עדיין יש גישה אם יש לו גישה לילד או לילדה בתור קורא. לחלופין, גם אם רשימת ה-ACL של פריט ההורה מעניקה גישה אל למשתמש אין גישה אם הוא לא קורא של הילד או הילדה.PARENT_OVERRIDE
- הגדרת סוג הירושה כ-PARENT_OVERRIDE
כדי לאלץ את ש-ACL של פריט ההורה יקבל קדימות על פני רשימת ה-ACL של פריט הצאצא כאשר הוא שיש התנגשות. כך, אם ה-ACL של פריט הצאצא מונע גישה למשתמש כדחייה ב-Reader, למשתמש עדיין יש גישה אם יש לו גישה לפריט ההורה בתור בקורא. לעומת זאת, גם אם רשימת ה-ACL של פריט הצאצא מעניקה גישה למשתמש, למשתמש אין גישה אם הוא לא קורא של פריט ההורה.
כאשר מעריכים שרשרת ירושה של ACL, סדר ההערכה עשוי להשתנות התוצאה של החלטת ההרשאה. Cloud Search מספק עלה לשורש סדר ההערכה לשרשראות ירושה של ACL. באופן ספציפי, ההחלטה לגבי רשימת ה-ACL ברשת מסוימת מתחילים בהערכת הילד או הילדה עם ההורים, והיא יכולה להתקדם כל הדרך עד ההורה הבסיסי (root).
לדוגמה, אם לילד או לילדה יש סוג ירושה של CHILD_OVERRIDE
ולמשתמש
יש ל-Drive גישה לילד או לילדה, והם לא צריכים לבדוק את בקרת ההורים ב-Drive.
עם זאת, אם לילד או לילדה יש PARENT_OVERRIDE או BOTH_PERMIT, אז Drive ימשיך
להערכת הירושה במעלה השרשרת.
מחיקת מקום מארח ופריט
כשמוסיפים פריט לאינדקס, אפשר להוסיף לו תווית כמאגר באמצעות
setContainer()
של
IndexingItemBuilder
בכיתה. הקשר בין הקונטיינר לבין הקונטיינר מבסס את ההרכב הפיזי
של פריטים ומבטיחה שהפריטים נמחקו כראוי.
כשמוחקים מאגר תגים, גם הפריטים שכלולים בו נמחקים.
קשרי הפרדה אינם תלויים לחלוטין מכללי הירושה של ACL. לדוגמה, קובץ במערכת קבצים יכול להכיל תיקייה של למחוק אותה, אבל לקבל בירושה את ה-ACL מתיקייה אחרת. מחיקה של לא תמחק פריטים שירשו את רשימת ה-ACL שלה, אלא אם גם הפריטים האלה בהיררכיית הגבולות של התיקייה.
בקרות הגישה האלה מיוצגות באיור 2:
- משתמש 1 הוא חשבון משתמש ישיר שמותר על ידי פריט א'.
- משתמש 2 הוא חשבון משתמש ישיר מורשה של פריט ב'.
- משתמש 3 הוא חשבון משתמש ישיר מורשה של פריט ג'.
- פריט ג' יורש את רשימת ה-ACL של פריט א'.
- פריט ב' נותן לפריט א' את השם של פריט א' כמאגר שלו.
- פריט ג' נותן לפריט ב' את השם של פריט ב' כמאגר שלו.
כללי הגישה מבוססים על בקרות הגישה:
- גישה עקיפה מגיעה מ
setInheritFrom()
. לכן, משתמש 1 יכול לגשת לפריט ג' כי פריט ג' יורש את רשימת ה-ACL של פריט א'. - גישה עקיפה לא מגיעה מפריט ג' שנמצא כלול בפריט ב'. לכן, משתמש 2 לא יכול לגשת לפריט ג'.
![שרטוט של חיבורים בין פריטים](https://developers.google.cn/static/cloud-search/images/doc-hierarchy-SDK.png?authuser=0000&hl=he)
setInheritFrom()
שנמצאת בשימוש.בעזרת ההפרדה בין ירושה של ACL מהיררכיית הגבולות מאפשרת ליצור מודל מבנים קיימים רבים ושונים.
כשפריט נמחק בהצלחה:
- כל פריט שמכיל פריט שנמחק הופך לבלתי ניתן לחיפוש תוזמן למחיקה ממקור הנתונים של Google.
- כל פריט שצוין בו את הפריט שנמחק באמצעות
אמצעי תשלום
setInheritFrom()
הופך לבלתי ניתן לחיפוש.
אם משאב מכיל פריט שנמחק באמצעות
setInheritFrom()
אבל לא הוגדר בה קונטיינר באמצעות
הפריט setContainer()
או היררכיית ההכללה שלו לא מכילים פריטים שנמחקו, הפריט והנתונים שלו
נשארים במקור הנתונים של Google. האחריות למחיקת הפריט היא שלך.
באיור 3 מוצגת דוגמה לאופן שבו המחיקה פועלת בהיררכיית פריטים.
![שרטוט של חיבורים בין פריטים](https://developers.google.cn/static/cloud-search/images/doc-hierarchy-deletion-SDK.png?authuser=0000&hl=he)
בקרות הגישה האלה מיוצגות באיור 3:
- משתמש 1 הוא חשבון משתמש ישיר שמותר על ידי פריט א'.
- משתמש 2 הוא חשבון משתמש ישיר מורשה של פריט ד'.
- פריט ד' ופריט E יורשים את רשימת ה-ACL של פריט א'.
- פריט ד' נותנים שם לפריט א' כמאגר שלו.
- פריטים א' ו-E הם פריטים ברמה הבסיסית (root) כי אין להם פריט במאגר.
מחיקת מדורגת דרך הפניות הקונטיינר. כשפריט א' נמחק:
- כל הצאצאים של
setInheritFrom()
קובצי עזר יאבדו את הגישה לכל המשתמשים. - אף משתמש לא יכול לגשת לפריט א'.
- פריט ד' נמחק באופן לא מפורש. אף משתמש לא יכול לגשת לפריט ד'.
- פריט ה' לא נמחק, מכיוון שהמחיקה עוברת רק אל המאגר הפניות.
- פריט ה' הופך לבלתי נגיש ואף משתמש לא יכול לחפש את פריט E.