בקצרה: אם בניתם אפליקציה ב-Lovable או בכלי דומה, כנראה יש מתחתיה בסיס נתונים של Supabase. לא צריך ללמוד אותו כולו. צריך לדעת איפה ששה דברים נמצאים, ולעשות בכל אחד צעד ראשון אחד. כל צעד כאן לוקח רבע שעה או פחות.
לפני שמתחילים: איפה הלוח שלכם?
רעיון ראשון: פתחו את הלוח וחפשו את רשימת הטבלאות.
- חיברתם פרויקט Supabase משלכם: היכנסו ל-supabase.com, בחרו את הפרויקט, ופתחו את Table Editor.
- השתמשתם ב-backend המובנה של Lovable (Cloud): בפרויקט ב-Lovable פתחו את תפריט More ובחרו Database. לפי התיעוד של Lovable, שם רואים את הטבלאות ועורכים רשומות, ולידו Users, Storage, Secrets ו-Logs.
מצאתם? יש לכם את כל מה שצריך להמשך.
שלב 1: הטבלאות
כל מה שהאפליקציה שומרת יושב בטבלאות: משתמשים, הזמנות, הודעות, קבצים שהועלו.
רעיון ראשון: עברו על רשימת הטבלאות וסמנו ליד כל אחת אם יש בה מידע אישי של משתמשים (שם, טלפון, מייל, תוכן שהם כתבו). את הרשימה הזו תצטרכו בשלב הבא.
שלב 2: RLS, מי רואה מה
RLS (Row Level Security) הוא הכלל שקובע איזה משתמש רואה אילו שורות. לפי התיעוד של Supabase, המפתח שנמצא בקוד של האפליקציה גלוי לכל מי שפותח אותה, ולכן הוא מגיע רק למה ש-RLS מתיר.
רעיון ראשון: בכל טבלה שסימנתם בשלב 1, ודאו ש-RLS מופעל. ב-Table Editor טבלה בלי RLS מסומנת בבירור. מצאתם טבלה כזו? אל תפעילו RLS בלי מדיניות, כי אז האפליקציה תפסיק לראות את הנתונים. ההסבר המלא, כולל SQL: RLS ב-Supabase לא עובד.
נוספה טבלה חדשה והאפליקציה מקבלת שגיאה 42501? זה שינוי של Supabase מ-30.10.2026: permission denied for table.
שלב 3: המפתחות
יש שני סוגי מפתחות. לפי התיעוד של Supabase:
| מפתח | איפה מותר לשים אותו | מה הוא עושה |
|---|---|---|
| ציבורי (publishable, או anon בגרסה הישנה) | בקוד שמגיע לדפדפן או לטלפון | מגיע רק למה ש-RLS מתיר |
| סודי (secret, או service_role בגרסה הישנה) | רק בשרת, בפונקציה או במשימה מתוזמנת | עוקף את RLS ונותן גישה מלאה |
רעיון ראשון: חפשו בקוד של האפליקציה את המילים service_role ו-sb_secret. אם אחת מהן מופיעה בקוד שרץ בדפדפן, זה הדבר הראשון לתקן היום, וגם להחליף את המפתח.
שלב 4: התחברות משתמשים
הבעיה הנפוצה כאן היא קישור אימות או איפוס סיסמה שמוביל לכתובת הלא נכונה, למשל לכתובת התצוגה המקדימה במקום לדומיין שלכם.
רעיון ראשון: בלוח של Supabase פתחו Authentication, ואז URL Configuration, ובדקו שה-Site URL הוא הדומיין האמיתי שלכם. לפי התיעוד של Supabase, זו הכתובת שאליה מגיעים כשהאפליקציה לא מציינת כתובת אחרת.
שלב 5: גיבויים
לפי התיעוד של Supabase, גיבוי יומי אוטומטי קיים בתוכניות Pro, Team ו-Enterprise. לפרויקטים בתוכנית החינמית Supabase ממליצה לייצא את הנתונים בעצמכם באופן קבוע ולשמור עותק מחוץ לשירות.
רעיון ראשון: בדקו באיזו תוכנית הפרויקט שלכם. אם הוא בתוכנית החינמית ויש בו משתמשים אמיתיים, קבעו לעצמכם תזכורת קבועה לייצוא.
שלב 6: לוגים
כשמשהו נשבר אצל משתמש ולא אצלכם, הלוגים הם המקום הראשון שמראה למה.
רעיון ראשון: פתחו את Logs (ב-Supabase או ב-Lovable) ובחרו את השעה האחרונה. אתם לא צריכים להבין כל שורה. חפשו שורות אדומות, והעתיקו אחת כזו כשאתם פונים לעזרה. זה חוסך את השאלה הראשונה של כל מי שיבדוק.
ומה אם ב-Lovable הכלי משנה את בסיס הנתונים בעצמו?
לפי התיעוד של Lovable, להרשאה של הכלי לבצע שינוי במבנה בסיס הנתונים שעלול לשבור אפליקציה שכבר פורסמה (מחיקה או שינוי שם של טבלה או עמודה) יש שלוש אפשרויות: לא לאפשר אף פעם (ברירת המחדל), לשאול בכל פעם (ואז הכלי מראה את ה-SQL לפני שהוא מריץ אותו), או לאפשר תמיד. רעיון ראשון: פתחו ב-Lovable את Account settings, ואז Preferences ואז Agent permissions, ובדקו שההרשאה הזו לא הוגדרה ל"לאפשר תמיד". אם היא על "לשאול בכל פעם", אל תאשרו שינוי כזה בלי לקרוא מה נמחק.
מתי לעצור ולקבל עזרה
אם בשלב 2 מצאתם טבלה עם מידע אישי בלי RLS, או בשלב 3 מפתח סודי בקוד של הדפדפן, והאפליקציה כבר עם משתמשים: זה לא הזמן ללמוד תוך כדי. בדיקת אבטחה לפני השקה היא בדיוק הבדיקה הזו, על האפליקציה שלכם.
