הוספת תפקידי משתמש והרשאות אמיתיות
מתן דפים, פעולות וגישה שונים לבעלים, לצוות וללקוחות, שנאכפים על המידע המאוחסן.
מתי להשתמש בזה
כאשר מערכת ההתחברות כבר עובדת אך נדרשת הפרדה בדפים, בפעולות ובגישה למידע המאוחסן עבור בעלים, צוות ולקוחות.
לפני שמתחילים
- הרשמה והתחברות תקינות. השתמש בהנחיית האימות תחילה אם חשבונות עדיין לא קיימים.
- רשימה כתובה של התפקידים שאתה באמת צריך. התחל עם פחות תפקידים והוסף אחר רק כאשר ההרשאות שלו שונות באופן מהותי.
- מטריצת הרשאות פשוטה המציגה מה כל תפקיד רשאי לראות, ליצור, לשנות ולמחוק.
- חשבונות בדיקה נפרדים ובטוחים עבור כל תפקיד, בתוספת חלון דפדפן אחד מנותק.
- החלטה לגבי מי רשאי להקצות או לשנות תפקידים. זה בדרך כלל צריך להיות מוגבל לבעלים או למנהל מהימן בצורה מצומצמת.
הפרומפט
הפרומפטים האלה עובדים הכי טוב באנגלית — הדביקו אותם כמו שהם גם בדפים מתורגמים.
Add user roles and permissions to this existing app. Login already works. The roles are [ROLE ONE], [ROLE TWO] and [ROLE THREE]. Use these descriptions: [ROLE ONE CAN SEE AND DO], [ROLE TWO CAN SEE AND DO], and [ROLE THREE CAN SEE AND DO]. Before changing anything, show me a plain-language matrix with the roles down one side and the important pages, information and actions across the top. Mark what each role can view, create, change and delete. Include logged-out visitors. Flag any unclear or conflicting instruction instead of guessing. After I approve the matrix, enforce it on both the screens and the stored information. Hiding a menu item is not protection. If someone types a private page address directly or changes an item number in the address, the app must still refuse access to anything outside that person's permission. Use the safest default when a rule is missing: deny the action and show a calm message. A [CUSTOMER ROLE] may see and change only [THEIR OWN INFORMATION]. A [STAFF ROLE] may see and change [ASSIGNED OR SHARED INFORMATION]. A [OWNER ROLE] may manage [OWNER-ONLY AREAS]. Adjust these examples to match my approved matrix. Add an owner-only user management screen where [AUTHORIZED ROLE] can view a person's current role and change it. Users must never choose a more powerful role for themselves through sign-up, profile editing or a changed page address. Keep a small history showing who changed a role, whose role changed, the old role, the new role and the time. Do not confuse live app roles with builder access. Staff who use the finished app should not automatically gain access to the builder, project settings, private connection keys or deployment controls. Test with one account for every role and one logged-out window. Try the normal navigation, direct page addresses, viewing another person's record, changing allowed information and attempting one forbidden action. Do not use real customer accounts or data. Keep the existing design and make denied-access messages clear rather than frightening. Finish with the approved matrix, the test results and anything that remains broader than I requested.
כבר בונים? הדביקו את זה בפרויקט שלכם. מתחילים מאפס? פתחו חשבון חינמי באחת מפלטפורמות הבנייה המתאימות למטה.
בנו את זה ב־
מה זה יוצר
- מטריצת הרשאות בשפה פשוטה עבור כל תפקיד
- דפים מוגנים ומידע מאוחסן על סמך אותה מטריצה
- מסך לבעלים בלבד להקצאת תפקידים
- הגנה מפני קידום עצמי וגישה ישירה לכתובות
- היסטוריה קטנה של שינויי תפקידים
- תוצאות בדיקות מכל תפקיד ומבקר מנותק
בדקו שזה עבד
הדביקו את הפרומפט, המתינו לסיום הבנייה, ואז ודאו את אלה — בשפה פשוטה, בלי בדיקות טכניות:
- כל חשבון בדיקה רואה רק את הדפים והפעולות המיועדים לתפקיד שלו
- חשבון לקוח לא יכול לראות מידע של לקוח אחר
- חשבון צוות יכול להשלים את העבודה המותרת לו אך לא יכול לפתוח הגדרות של בעלים בלבד
- הקלדת כתובת דף אסורה ישירות מציגה הודעת גישה במקום תוכן פרטי
- משתמש רגיל לא יכול להעניק לעצמו תפקיד חזק יותר
- הבעלים המורשה יכול לשנות תפקיד בדיקה ולראות היסטוריה קריאה של השינוי הזה
- התנתקות מסירה את הגישה באופן מיידי
משהו חסר? זה נורמלי — בקשו אותו בהודעת המשך קצרה אחת במקום להריץ מחדש את כל הפרומפט.
השלבים הבאים
הוספת הזמנות לצוות
כאשר חוקי התפקידים עובדים ובעל המערכת זקוק לדרך בטוחה להוסיף חברי צוות
Add an owner-only invitation flow for [STAFF ROLE]. The owner enters [STAFF EMAIL] and chooses from [ALLOWED STAFF ROLES]. The invited person sets up their own login and receives only the selected live app role. Do not give them access to the builder or project settings.
תדעו שזה עבד כאשר: חשבון בדיקה מוזמן מצטרף עם תפקיד הצוות הנבחר ואינו יכול להיכנס לאזורים של בעל המערכת בלבד או לעורך הראשי.
הגבלת צוות לרשומות משויכות
כאשר אנשי הצוות צריכים לעבוד רק עם הלקוחות, המיקומים או המשימות שלהם
Change [STAFF ROLE] access so each staff member can view and update only records assigned to them through [ASSIGNMENT FIELD OR RULE]. Owners may still view all records. Test with two staff accounts and confirm neither can open the other's assigned record directly.
תדעו שזה עבד כאשר: כל חשבון בדיקה של איש צוות רואה רק את העבודה שהוקצתה לו, בעוד שבעל המערכת עדיין רואה את הרשימה המלאה.
בדיקת הרשאות לאחר תכונה חדשה
בכל פעם שמוסיפים דף, סוג נתונים או פעולת ניהול חדשה
Update the existing permission matrix for [NEW FEATURE]. Show what logged-out visitors and every current role can view, create, change and delete. Apply the narrowest approved rules, then repeat one allowed and one forbidden test for each affected role.
תדעו שזה עבד כאשר: התכונה החדשה מופיעה במטריצה ועוקבת אחר אותה מערכת הרשאות שנבדקה עבור שאר האפליקציה.
שימו לב ל
- תפקידי אפליקציה ותפקידי בונה הם שונים. מי שמנהל לקוחות בתוך האפליקציה המוגמרת לא זקוק אוטומטית להרשאה לערוך את האפליקציה עצמה.
- כפתורים מוסתרים אינם בקרת גישה. בדוק כתובות דפים ישירות ורשומה של אדם אחר; המידע המאוחסן חייב לדחות את הבקשה גם כאשר התפריט מסתיר אותה.
- יותר מדי תפקידים הופכים לבלתי אפשריים לניהול. התחל עם בעלים, צוות ולקוח אלא אם לתפקיד רביעי יש תחומי אחריות שונים בבירור.
- שינויי הרשאות יכולים להשפיע על משתמשים אמיתיים באופן מיידי. בדוק עם חשבונות לדוגמה ועיין במטריצה לפני החלת שינויים על אפליקציה חיה.
- תפקיד צוות רחב מדי עלול לחשוף יותר מהצפוי. אם הצוות צריך לראות רק לקוחות או מיקומים שהוקצו להם, ציין את הכלל הזה במפורש ובדוק עם שני חשבונות צוות.
הערות לפי פלטפורמה
<ul><li><strong>Base44:</strong> Base44 כוללת תפקידי אפליקציה חיים וחוקי גישה לנתונים, והיא יכולה ליצור תפקידים נוספים מעבר לברירות המחדל. משתפי פעולה ב-Builder נפרדים ממשתמשי האפליקציה, לכן אל תהפוך משתמש צוות למשתף פעולה אלא אם הוא באמת צריך לערוך את האפליקציה.</li><li><strong>Lovable:</strong> Lovable יכולה לבנות גישה מבוססת תפקידים עם Lovable Cloud או אחסון Supabase מחובר. בקש הגנה על המידע המאוחסן, לא רק על הדפים הגלויים, ובדוק כל תפקיד לאחר הפרסום.</li><li><strong>v0:</strong> v0 זקוקה לשירות התחברות ונתונים מחובר עבור הרשאות אמיתיות. היא יכולה לבנות את המסכים ואת הבדיקות הפרטיות, אך ספק האחסון המדויק חייב לאכוף מי יכול לקרוא או לשנות את המידע של כל אדם.</li></ul>
לחסוך בקרדיטים
כל פלטפורמה מחייבת אתכם על העבודה שה-AI שלה עושה — ולכן ההרגל הזול ביותר הוא לחשוב לפני שבונים. שישה כללים שחוסכים את רוב הבזבוז, בכל פלטפורמה שתבחרו.
- תכננו קודם בצ'אט חינמי. שרטטו את הכול ב-ChatGPT, ב-Claude או ב-Gemini — עמודים, פיצ'רים, מה כל טופס אוסף, איך זה צריך להיראות. לחשוב שם זה בחינם; לחשוב בתוך פלטפורמת בנייה זה בתשלום.
- התחילו מפרומפט כתוב, לא ממשפט. "תבנה לי אתר" הוא המשפט היקר ביותר בבנייה עם AI. פרומפט ראשון מלא — כמו אלה שבאתר הזה — חוסך עשרות סבבי תיקונים.
- אל תתעצלו בפרטים. כל פרט שתשמיטו יחזור כתיקון שתשלמו עליו. שם העסק, צבעים, כל עמוד, כל שדה בטופס, מה קורה אחרי שליחה — הכניסו הכול לפרומפט הראשון.
- אחר כך — שינוי אחד בכל הודעה. "תקן את הכותרת, וגם את הטופס, וגם את הצבעים" יוצר סבך שעולה יותר לפרום ממה שנחסך.
- נתקעתם? הפסיקו לטלאי. אם אותו תיקון נכשל בערך שלוש פעמים, אל תשלחו תיקון רביעי — תארו במקום זה את המצב הסופי הרצוי של כל המקטע בהודעה חדשה אחת.
- התחילו בחינם. שדרגו כשתצטרכו יותר. השתמשו במכסה החינמית כדי לבנות ולגלות את הגרסה הראשונה שלכם. שדרגו כשתצטרכו יותר שימוש או פיצ'רים בתשלום, ובדקו את העלויות של שירותים מחוברים לפני ההשקה.
הפרומפטים בעמוד הזה כתובים כך שיעשו את רוב העבודה הזאת בשבילכם — זו כל המטרה שלהם.
קראו את המדריך המלאפרומפטים קשורים
נבדק לאחרונה: 2026-07-27