רשימות של בקרת גישה (ACL)

שימוש

בדף הזה מובאת סקירה כללית על רשימות של בקרת גישה (ACL), שמאפשרות לכם לשלוט בגישה לקטגוריות או לאובייקטים ספציפיים. דרכים נוספות של בקרת גישה לקטגוריות ולאובייקטים מופיעות במאמר סקירה כללית של בקרת גישה.

האם כדאי להשתמש ברשימות של בקרת גישה?

ברוב המקרים, מומלץ להימנע משימוש ברשימות ACL ולהפעיל גישה אחידה ברמת הקטגוריה בקטגוריות, כדי למנוע שימוש ברשימות ACL:

  • אי אפשר להשתמש רק ברשימות ACL כדי לשלוט בגישה למשאבים שלכם, מפני שלא ניתן להגדיר אותן בפרויקט כולו או במשאבים מחוץ ל-Cloud Storage. Google Cloud
  • הפעלת גישה אחידה ברמת הקטגוריה יוצרת ממשק פשוט יותר לבקרת גישה ומאפשרת לכם להשתמש בתכונות נוספות Google Cloud . מידע נוסף זמין במאמר בנושא האם כדאי להשתמש בגישה אחידה ברמת הקטגוריה.
  • מדיניות הארגון domain restricted sharing ומדיניות ארגון בהתאמה אישית לא מונעות גישה שניתנת על ידי רשימות ACL, ולכן עלולה להיות גישה לא מכוונת.
  • התנהגויות וגישה לא צפויות עלולות להתרחש כשמשתמשים ברשימות ACL בפרויקטים שבהם מוגדרים תנאי IAM ברמת הפרויקט או ברמה גבוהה יותר.

כדאי להשתמש ברשימות ACL במקרים הבאים:

  • אתם צריכים להתאים אישית את הגישה לאובייקטים בודדים בתוך קטגוריה, למשל אם אתם רוצים שהמשתמש שהעלה אובייקט מסוים יוכל לשלוט בו באופן מלא, אבל תהיה לו גישה מוגבלת יותר לאובייקטים אחרים בקטגוריה.
  • אתם משתמשים רק ב-API בפורמט XML או שאתם צריכים יכולת פעולה הדדית עם Amazon S3.

מהי רשימה של בקרת גישה?

רשימה של בקרת גישה (ACL) היא מנגנון שאפשר להשתמש בו כדי להגדיר למי תהיה גישה לקטגוריות ולאובייקטים, וגם מה תהיה רמת הגישה. ב-Cloud Storage מחילים את רשימות ה-ACL על קטגוריות ואובייקטים בודדים. כל רשימת ACL מורכבת מרשומה אחת או יותר. רשומה מעניקה למשתמש מסוים (או לקבוצה) את היכולת לבצע פעולות ספציפיות. כל רשומה מכילה שני פריטי מידע:

  • הרשאה, שמגדירה אילו פעולות אפשר לבצע (לדוגמה, קריאה או כתיבה).

  • היקף (נקרא לפעמים מקבל ההרשאה), שמגדיר מי יכול לבצע את הפעולות שצוינו (לדוגמה, משתמש מסוים או קבוצת משתמשים מסוימת).

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

  • רשומה אחת תעניק הרשאת READER להיקף של allUsers.

  • הרשומה השנייה תעניק הרשאת WRITER להיקף של שותף העריכה (יש כמה דרכים לציין את האדם הזה, למשל באמצעות כתובת האימייל).

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

כשמשתמש מבקש גישה לקטגוריה או לאובייקט, מערכת Cloud Storage קוראת את רשימת ה-ACL של הקטגוריה או האובייקט וקובעת אם לאשר או לדחות את בקשת הגישה. אם רשימת ה-ACL מעניקה למשתמש הרשאה לביצוע הפעולה המבוקשת, הבקשה מורשית. אם רשימת ה-ACL לא מעניקה למשתמש הרשאה לפעולה המבוקשת, הבקשה תיכשל ותוחזר השגיאה 403 Forbidden.

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

הרשאות

הרשאות מתארות מה אפשר לעשות באובייקט או בקטגוריה מסוימים.

ב-Cloud Storage אפשר להקצות את ההרשאות הקונצנטריות הבאות לקטגוריות ולאובייקטים, כפי שמוצג בטבלה הבאה:

קטגוריות אובייקטים
READER מאפשרת למשתמש להציג ברשימה את תוכן הקטגוריה. מאפשרת למשתמש גם לקרוא את המטא-נתונים של הקטגוריה, מלבד רשימות ACL. מאפשרת למשתמש להוריד את נתוני האובייקט.
WRITER נותנת למשתמש את כל הגישה שמעניקה ההרשאה READER. בנוסף, מאפשרת למשתמש ליצור, להחליף ולמחוק אובייקטים בקטגוריה, כולל יצירת אובייקטים באמצעות העלאות מרובות חלקים. לא רלוונטית. אי אפשר להחיל את ההרשאה הזו על אובייקטים.
OWNER נותנת למשתמש את כל הגישה שמעניקה ההרשאה WRITER. מאפשרת למשתמש גם לקרוא ולכתוב מטא-נתונים של קטגוריה, כולל רשימות ACL, ולעבוד עם תגים בקטגוריה. נותנת למשתמש את כל הגישה שמעניקה ההרשאה READER. מאפשרת למשתמש גם לקרוא ולכתוב מטא-נתונים של אובייקטים, כולל רשימות ACL.
ברירת מחדל כאשר יוצרים קטגוריות, מוחלת עליהן רשימת ה-ACL המוגדרת מראש project-private. קטגוריות תמיד נמצאות בבעלות הקבוצה project-owners. כאשר מעלים אובייקטים, מוחלת עליהם רשימת ה-ACL המוגדרת מראש project-private. אובייקטים הם תמיד בבעלות של מגיש הבקשה המקורי שהעלה את האובייקט.

בדף הזה אנחנו מתייחסים באופן כללי להרשאות בתור READER, WRITER או OWNER – כך הן נקראות ב-API בפורמט JSON ובמסוףGoogle Cloud . אם אתם משתמשים ב-API בפורמט XML, ההרשאות המקבילות הן READ, WRITE ו-FULL_CONTROL, בהתאמה.

היקפים

היקפים מציינים למי יש הרשאה מסוימת.

רשימת ACL כוללת רשומה אחת או יותר, וכל רשומה מעניקה הרשאות להיקף מסוים. אפשר לציין את ההיקף ב-ACL באמצעות כל אחת מהישויות הבאות:

היקף ('מקבל ההרשאה') סוג הישות דוגמה
מזהה מיוחד לכל הישויות משתמש allUsers
מזהה מיוחד לכל החשבונות התקינים משתמש allAuthenticatedUsers
כתובת האימייל של חשבון המשתמש משתמש jeffersonloveshiking@gmail.com
כתובת אימייל של חשבון שירות משתמש my-service-account@my-project.iam.gserviceaccount.com
כתובת אימייל של קבוצה ב-Google קבוצה work-group@googlegroups.com
ערכי נוחות לפרויקטים פרויקט owners-123456789012
דומיין ב-Google Workspace דומיין dana@example.com
‏דומיין Cloud Identity דומיין dana@example.com

  • מזהה מיוחד לכל הישויות:

    מזהה ההיקף המיוחד allUsers מייצג כל ישות באינטרנט. שימו לב: המזהה הזה הוא ישות מסוג User, אבל כשמשתמשים במסוף Google Cloud הוא מסומן כישות מסוג Public.

  • מזהה מיוחד לכל החשבונות התקינים:

    מזהה ההיקף המיוחד allAuthenticatedUsers מייצג את רוב החשבונות המאומתים, כולל חשבונות שירות. מידע נוסף זמין במאמר חשבונות משתמשים ב-IAM. שימו לב: המזהה הזה הוא ישות מסוג User, אבל כשמשתמשים במסוף Google Cloud הוא מסומן כישות מסוג Public.

  • כתובת האימייל של חשבון המשתמש:

    לכל משתמש עם חשבון משתמש חייבת להיות כתובת אימייל ייחודית שמשויכת לאותו חשבון. אפשר לציין היקף באמצעות כל כתובת אימייל שמשויכת לחשבון משתמש.

    כתובות אימייל נשמרות ב-Cloud Storage כפי שהן מופיעות ברשימות ה-ACL, עד שמסירים או מחליפים את הרשומות. אם משתמש משנה את כתובות האימייל שלו, אתם צריכים לעדכן את רשומות ה-ACL בהתאם לשינוי.

  • כתובת האימייל של חשבון השירות:

    לכל חשבון שירות יש כתובת אימייל ייחודית שמשויכת אליו. אפשר לציין היקף באמצעות כתובת האימייל שמשויכת לחשבון השירות.

  • כתובת אימייל של קבוצה ב-Google:

    לכל קבוצה ב-Google יש כתובת אימייל מיוחדת שמשויכת אליה. לדוגמה, לקבוצה Cloud Storage Announce יש את כתובת האימייל הבאה: gs-announce@googlegroups.com. אפשר למצוא את כתובת האימייל שמשויכת לקבוצה ב-Google בלחיצה על About בדף הבית של כל קבוצה ב-Google.

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

  • ערכי נוחות לפרויקטים:

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

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

  • ‫Google Workspace או Cloud Identity:

    לקוחות Google Workspace ו-Cloud Identity יכולים לשייך את חשבונות האימייל שלהם לשם דומיין באינטרנט. כשעושים את זה, כל אחד מחשבונות האימייל יהיה בפורמט ‎USERNAME@YOUR_DOMAIN.com. אפשר לציין היקף באמצעות כל שם דומיין באינטרנט שמשויך ל-Google Workspace או ל-Cloud Identity.

הרשאות והיקפים קונצנטריים

כשמציינים רשימות ACL ב-Cloud Storage, אתם לא צריכים לפרט היקפים רבים כדי להעניק הרשאות רבות. ‫Cloud Storage משתמש בהרשאות קונצנטריות, כך שכאשר מעניקים הרשאת WRITER תוענק גם ההרשאה READER, ואם מעניקים הרשאת OWNER יוענקו גם ההרשאות READER ו-WRITER.

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

ב-API בפורמט XML אי אפשר לציין שתי רשומות ACL עם אותו היקף. לדוגמה, אם מעניקים למשתמש את ההרשאה READ ואת ההרשאה WRITE בקטגוריה, מתקבלת הודעת שגיאה. במקום זאת, אתם צריכים להעניק למשתמש את ההרשאה WRITE, שמעניקה למשתמש גם את ההרשאה READ.

רשימות ACL ו-IAM

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

התנהגות עם דחיית IAM

מדיניות דחייה ב-IAM מבטלת כל גישה רלוונטית שמוענקת על ידי רשימת ACL שהגדרתם, אם מדיניות הדחייה ורשימת ה-ACL מכוונות לאותה הרשאה.

לדוגמה, אם לקטגוריה יש מדיניות דחייה שמונעת ממשתמש לקבל את ההרשאה storage.objects.get, ואתם יוצרים ACL שמעניק למשתמש את התפקיד READER באובייקט בקטגוריה, המשתמש לא יוכל לצפות באובייקט בקטגוריה. עם זאת, אם מדיניות הדחייה מציינת את ההרשאה storage.buckets.get ורשימת ה-ACL מעניקה את התפקיד storage.buckets.get בקטגוריה, המשתמש לא יוכל לאחזר את המטא-נתונים של הקטגוריה, אבל עדיין יוכל לרשום, ליצור ולמחוק אובייקטים בקטגוריה.WRITER

רשימות ACL מוגדרות מראש

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

הטבלה הבאה מפרטת רשימות ACL מוגדרות מראש, ומראה אילו רשומות ACL חלות על כל רשימת ACL מוגדרת מראש. כשמשתמשים בטבלה חשוב לשים לב לדברים הבאים:

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

  • בטבלה נעשה שימוש בתיאורי ההרשאות ב-API בפורמט JSON: OWNER, WRITER ו-READER. ההיקפים המקבילים ב-API בפורמט XML הם FULL_CONTROL, WRITE ו-READ.

    ‫API בפורמט JSON / gcloud storage ‫API בפורמט XML תיאור
    private private מעניקה לבעלים של הקטגוריה או האובייקט את ההרשאה OWNER לקטגוריה או לאובייקט.
    bucketOwnerRead bucket-owner-read מעניקה לבעלים של האובייקט את ההרשאה OWNER, ומעניקה לבעלי הקטגוריה את ההרשאה READER. משתמשים בה רק עם אובייקטים.
    bucketOwnerFullControl bucket-owner-full-control מעניקה לבעלים של האובייקט והקטגוריה את ההרשאה OWNER. משתמשים בה רק עם אובייקטים.
    projectPrivate project-private מעניקה לחברי צוות הפרויקט הרשאה בהתאם לתפקיד שלהם. לכל מי שחבר בצוות יש הרשאת READER. לבעלים ולעורכים של הפרויקט יש הרשאת OWNER. זו רשימת ה-ACL שמשמשת כברירת המחדל לקטגוריות חדשות שנוצרו. זו גם רשימת ה-ACL שמשמשת כברירת המחדל לאובייקטים חדשים שנוצרו, אלא אם שונתה רשימת ה-ACL שמשמשת כברירת המחדל של האובייקטים בקטגוריה הזו.
    authenticatedRead authenticated-read מעניקה לבעלים של הקטגוריה או האובייקט את ההרשאה OWNER, ולכל בעלי חשבונות המשתמשים המאומתים את ההרשאה READER.
    publicRead public-read מעניקה לבעלים של הקטגוריה או האובייקט את ההרשאה OWNER, ומעניקה את ההרשאה READER לכל המשתמשים – גם למשתמשים מאומתים וגם למשתמשים אנונימיים. כשמחילים את רשימת ה-ACL הזו על אובייקט, כל אחד באינטרנט יוכל לקרוא את האובייקט ללא אימות. כשמחילים אותה על קטגוריה, כל משתמש באינטרנט יכול להציג את רשימת האובייקטים ללא אימות.

    * ראו את ההערה שבסוף הטבלה לגבי שמירה במטמון.
    publicReadWrite public-read-write מעניקה לבעלים של הקטגוריה את ההרשאה OWNER, ומעניקה לכל המשתמשים, גם מאומתים וגם אנונימיים, את ההרשאות READER ו-WRITER. רשימת ה-ACL הזו חלה רק על קטגוריות. כשמחילים את רשימת ה-ACL הזו על קטגוריה, כל משתמש באינטרנט יכול להציג ברשימה אובייקטים ללא אימות, וכן ליצור, להחליף ולמחוק אותם.

    * ראו את ההערה שבסוף הטבלה לגבי שמירה במטמון.

* כברירת מחדל, אובייקטים שניתנים לקריאה באופן ציבורי מוצגים עם הכותרת Cache-Control, שמאפשרת לשמור את האובייקטים במטמון למשך 3600 שניות. אם אתם רוצים להבטיח שהעדכונים יהיו גלויים באופן מיידי, כדאי להגדיר את המטא-נתונים Cache-Control של האובייקטים ל-Cache-Control:private, max-age=0, no-transform.

רשימות ACL שמשמשות כברירת מחדל

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

רשימות ACL שמשמשות כברירת מחדל של קטגוריות

כל הקטגוריות הן בבעלות של קבוצת בעלי הפרויקט. בנוסף, בעלי הפרויקט מקבלים את ההרשאה OWNER לכל הקטגוריות בפרויקט שמשתמשות ברשימת ACL מוגדרת מראש.

אם יוצרים קטגוריה עם רשימת ה-ACL שמשמשת כברירת המחדל של קטגוריות, כלומר לא מציינים רשימת ACL מוגדרת מראש כשיוצרים את הקטגוריה – תחול על הקטגוריה הזו רשימת ה-ACL המוגדרת מראש projectPrivate.

רשימות ACL שמשמשות כברירת מחדל של אובייקטים

כברירת מחדל, כל מי שיש לו את ההרשאה OWNER או את ההרשאה WRITER בקטגוריה יכול להעלות אובייקטים לאותה קטגוריה. כשמעלים אובייקט, ניתן לספק רשימת ACL מוגדרת מראש או לא לציין ACL בכלל. אם לא מציינים רשימת ACL,‏ Cloud Storage מחיל על האובייקט את רשימת ACL שמשמשת כברירת המחדל. לכל קטגוריה יש רשימת ACL שמשמשת כברירת מחדל של אובייקטים, והרשימה הזו מוחלת על כל האובייקטים שהועלו לקטגוריה בלי רשימת ACL מוגדרת מראש או בלי ציון ACL בבקשה (API בפורמט JSON בלבד). הערך הראשוני של רשימת ה-ACL שמשמשת כברירת המחדל של האובייקטים בכל קטגוריה הוא projectPrivate.

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

  • העלאות מאומתות

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

    • אתם (מי שהעלה את האובייקט) רשומים כבעלים של האובייקט. אי אפשר לשנות את הבעלות על האובייקט על ידי שינוי רשימות ה-ACL. אפשר לשנות את הבעלות על האובייקט רק על ידי החלפת אובייקט.

    • אתם (הבעלים של האובייקט) מקבלים את ההרשאה OWNER באובייקט. אם תנסו לתת לבעלים הרשאה נמוכה מ-OWNER, Cloud Storage יעלה אוטומטית את ההרשאה ל-OWNER.

    • לבעלים של הפרויקט ולקבוצת עורכי הפרויקט יש הרשאת OWNER באובייקט.

    • לקבוצת החברות בצוות הפרויקט יש הרשאת READER באובייקט.

  • העלאות אנונימיות

    אם משתמש לא מאומת (אנונימי) מעלה אובייקט, וזה יכול לקרות אם קטגוריה מעניקה לקבוצה allUsers את ההרשאה WRITER או OWNER, יחולו על האובייקט רשימות ה-ACL שמשמשות כברירת המחדל של קטגוריות כפי שמתואר למעלה.

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

ההתנהגות של רשימת ACL

‫Cloud Storage עוזר לכם לפעול בהתאם לשיטות המומלצות על ידי אכיפה של מספר כללים לשינוי רשימת ACL, וכך מונע מכם להגדיר רשימות ACL שלא מאפשרות גישה לנתונים:

  • אי אפשר להחיל רשימת ACL שמציינת קטגוריה אחרת או בעלי אובייקט אחרים.

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

  • לבעלים של הקטגוריה או האובייקט תמיד יש הרשאת OWNER לקטגוריה או לאובייקט.

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

    אם מחילים רשימת ACL חדשה על קטגוריה או על אובייקט ומשמיטים את ההרשאות, Cloud Storage יוסיף את ההרשאה OWNER לבעלי הקטגוריה או לבעלי האובייקט, בהתאמה. הפעולה לא מעניקה לקבוצת בעלי הפרויקט את ההרשאה OWNER על האובייקט (אלא אם האובייקט נוצר על ידי משתמש אנונימי), ולכן עליכם לכלול את ההרשאה הזו באופן מפורש.

אי אפשר להחיל רשימות ACL שמשנות את הבעלות על קטגוריה או אובייקט (אל תתבלבלו בין הבעלות לבין ההרשאה OWNER). אחרי שיוצרים קטגוריות ואובייקטים ב-Cloud Storage, אי אפשר לשנות את הבעלות עליהם. עם זאת, אפשר לשנות בפועל את הבעלות על אובייקטים (אבל לא על קטגוריות) על ידי החלפתם. החלפה היא בעצם פעולת מחיקה ומיד אחריה פעולת העלאה. במהלך פעולת העלאה, האדם שמבצע את ההעלאה הופך לבעלים של האובייקט. חשוב לזכור שכדי להחליף אובייקט, לאדם שמבצע את ההחלפה (וכך מקבל את הבעלות על האובייקט) צריכה להיות הרשאת WRITER או OWNER בקטגוריה שאליה הוא מעלה את האובייקט.

המאמרים הבאים