הגדרת בקרת גישה ב-Payload CMS

מפתחים מתחילים לעיתים קרובות מנסים להגדיר הרשאות ב-Payload CMS באמצעות middleware או משתנים גלובליים. זה מוביל לחורי אבטחה ולקוד מסורבל שקשה לתחזק. הצוות שלנו, עם ניסיון של למעלה מ-10 שנים בייצור עם TypeScript ו-Payload CMS, מציע גישה שונה: כל כלל גישה הוא פונקציית TypeScript טהורה של הקונטקסט של הבקשה. הפונקציה מחזירה true (גישה מותרת), false (נדחתה), או אובייקט תנאי ש-Payload מוסיף לשאילתת מסד הנתונים כ-MongoDB $match או SQL WHERE. גישה זו מפחיתה את נפח הקוד פי 3–4 בהשוואה ל-middleware ומבטלת את האפשרות לפספס בדיקות הרשאות. במקום קונפיגורציות YAML והגדרות GUI — רק קוד השולט בכל פעולה: קריאה, יצירה, עדכון, מחיקה. Payload CMS Access Control מתאר את העקרונות הבסיסיים — אנחנו נראה פתרונות מוכנים לתרחישים טיפוסיים שיושמו בהצלחה ביותר מ-15 פרויקטים מסחריים.

איך פונקציות גישה עובדות

כל פונקציית גישה מקבלת אובייקט עם req (כולל req.user) ואופציונלית id של המסמך. תוצאה:

• true — לאפשר ללא הגבלות;
• false — לדחות;
• אובייקט Where — פילטר ש-Payload מוסיף לשאילתת מסד הנתונים. המשתמש רואה רק מסמכים שעומדים בתנאי — זה מבטל סינון לאחר הבקשה.

// Функция доступа получает: req (с req.user), id (для операций над конкретным документом)
type AccessFunction = ({
  req,
  id,
}: {
  req: PayloadRequest;
  id?: string | number;
}) => boolean | Where | Promise<boolean | Where>;

הגדרת בקרת גישה שלב אחר שלב

1. עיצוב מודל התפקידים. קבע אילו תפקידים נדרשים (מנהל, עורך, מחבר, לקוח) ואילו זכויות יש להם.
2. הוסף שדה תפקיד לאוסף המשתמשים. השתמש ב-select והגדר זכויות גישה לשינוי שלו.
3. יישם פונקציות גישה לכל אוסף. התחל עם read ו-create.
4. הגדר הגבלות ברמת שדה. הסתר או חסום עריכה של שדות רגישים.
5. בדוק תרחישים. ודא שמשתמשים אנונימיים לא רואים מסמכים פרטיים (חסימה של 100%), ומחבר לא יכול למחוק מסמכים של אחרים (חסימה של 95% אם מוגדר נכון).

מקרה בוחן: גישה רב-רמות לפלטפורמה רפואית

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

הגדרת גישה לאוספים: תפקידים ושדות

דוגמה להגדרת אוסף המשתמשים עם תפקידים והגבלה על שינוי התפקיד:

// collections/Users.ts
const Users: CollectionConfig = {
  slug: 'users',
  auth: true,
  fields: [
    {
      name: 'firstName',
      type: 'text'
    },
    {
      name: 'lastName',
      type: 'text'
    },
    {
      name: 'role',
      type: 'select',
      options: [
        {
          label: 'Администратор',
          value: 'admin'
        },
        {
          label: 'Редактор',
          value: 'editor'
        },
        {
          label: 'Автор',
          value: 'author'
        },
        {
          label: 'Клиент',
          value: 'customer'
        },
      ],
      required: true,
      defaultValue: 'author',
      access: {
        // Только admin может менять роль
        update: ({ req }) => req.user?.role === 'admin',
      },
    },
  ],
}

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

// collections/Posts.ts
const Posts: CollectionConfig = {
  slug: 'posts',
  access: {
    read: ({ req }) => {
      if (req.user?.role === 'admin' || req.user?.role === 'editor') return true
      return { status: { equals: 'published' } }
    },
    create: ({ req }) => ['admin', 'editor', 'author'].includes(req.user?.role || ''),
    update: ({ req }) => {
      if (!req.user) return false
      if (['admin', 'editor'].includes(req.user.role)) return true
      if (req.user.role === 'author') return { author: { equals: req.user.id } }
      return false
    },
    delete: ({ req }) => req.user?.role === 'admin',
  },
}

איך לארגן גישה מרובת דיירים?

לתוכניות מרובות דיירים — גישה דרך ארגון מקושר. המשתמש רואה רק מסמכים של הארגון שלו, מנהל רואה הכל:

// collections/Documents.ts
{
  slug: 'documents',
  access: {
    read: ({ req }) => {
      if (!req.user) return false
      if (req.user.role === 'admin') return true
      return {
        organization: {
          equals: req.user.organization
        }
      }
    },
    update: ({ req }) => {
      if (!req.user) return false
      if (req.user.role === 'admin') return true
      return {
        and: [
          {
            organization: {
              equals: req.user.organization
            }
          },
          {
            lockedBy: {
              not_equals: req.user.id
            }
          },
        ]
      }
    },
  },
}

אבטחת נקודות קצה API מותאמות אישית

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

// Кастомный эндпоинт с проверкой доступа
{
  path: '/export',
  method: 'get',
  handler: async (req: PayloadRequest, res: Response) => {
    if (!req.user) return res.status(401).json({ error: 'Unauthorized' })
    if (!['admin', 'editor'].includes(req.user.role)) {
      return res.status(403).json({ error: 'Insufficient permissions' })
    }
    await req.payload.create({
      collection: 'audit-logs',
      data: {
        action: 'export',
        user: req.user.id,
        timestamp: new Date().toISOString(),
      },
    })
    const data = await req.payload.find({
      collection: 'documents',
      limit: 10000,
    })
    return res.json(data)
  },
}

תנאי Where לעומת פילטר לאחר: השוואה

טבלת הרשאות תפקידים (דוגמה)

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

• [ ] תפקידים והרשאותיהם הוגדרו
• [ ] שדה תפקיד במשתמשים הוגדר עם הגבלת עדכון
• [ ] פונקציות גישה נכתבו לכל אוסף
• [ ] הגבלות ברמת שדה לנתונים רגישים
• [ ] התנהגות משתמש אנונימי נבדקה
• [ ] תרחישים עם תפקידים שונים נבדקו
• [ ] נקודות קצה מותאמות אישית נבדקו

לוחות זמנים ומה כלול

הגדרת מערכת תפקידים ובקרת גישה לפרויקט עם 3–5 תפקידים ו-5–10 אוספים אורכת 2–3 ימים במפתח מלא. כולל:

• עיצוב מודל תפקידים (יום אחד)
• יישום פונקציות גישה לכל האוספים (1–2 ימים)
• אבטחת נקודות קצה API מותאמות אישית (0.5 יום)
• ביקורת אבטחה ובדיקת עומסים (0.5 יום)
• תיעוד על תפקידים והרשאות (בפורמט README)

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