פרסמו את הפרויקט שלכם

אם כפתור הפרסום או העדכון מציג "יתרת הענן שלך אינה מספיקה לפרסום" או "יתרת הענן שלך אינה מספיקה לעדכון", הארנק בענן שלך אזל.

כדי לתקן זאת:

1. עבור אל הגדרות > ענן & AI כדי לבדוק את היתרה הנוכחית שלך.

2. בחר טען עכשיו והוסף כספים לארנק הענן שלך.

3. חזור ללוח הפרסום ונסה שוב.

הערה: ארנק הענן שלך נפרד מזיכויי המנוי שלך. ארנק הענן מממן שירותי אירוח ופריסה, בעוד שזיכויי המנוי משמשים לשיחות עם סוכן ה-AI.

1. בדוק את תצוגת השימוש באחסון וזהה את הצ'אטים, הפרויקטים והקבצים הגדולים ביותר.
2. הורד או גבה כל דבר שעשוי להידרש לך בהמשך.
3. מחק רק פריטים שאינם נחוצים. אם מחיקת צ'אט מציעה להסיר נתוני דיסק משויכים, בחר באפשרות הזו רק לאחר שאישרת שהנתונים בטוחים להשלכה.
4. רענן את הדף ואשר שנפח האחסון הזמין גדל.
5. חזור אל Publish ונסה שוב פעם אחת.

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

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

1. בחר Resolve All ובדוק את ההתנהגות שהושפעה. תקן בעיות שכוללות סודות חשופים, אימות, הרשאות, נתוני משתמשים או גישה חיצונית לא בטוחה לפני שימוש בייצור.
2. אם ייתכן שסוד נחשף, הסר אותו מהפרויקט ובצע לו רוטציה דרך הספק הרלוונטי לפני הפרסום.
3. הרץ את הסריקה שוב ואמת את הזרימה שהושפעה.
4. השתמש ב-Publish Anyway רק כאשר בודק אחראי מבין ומקבל את הסיכון הלא-קריטי שנותר. תעד את הסיבה והימנע מעקיפת סיכון לא פתור באתר ייצור.

אם אינך יכול לקבוע את ההשפעה של ממצא, אל תפרסם אותו. פנה לתמיכה או לאחראי האבטחה שלך עם טקסט הממצא וראיות שעברו סניטיזציה.

1. בדוק בנפרד את כתובת ה-URL של סביבת הייצור בפלטפורמה ואת הדומיין המותאם אישית. כמו כן, השווה בין דף השורש לבין הדף הספציפי או נתיב ה-API שנכשל.
2. תעד את קוד הסטטוס המדויק, כתובת ה-URL המלאה, השעה ואזור הזמן, והאם הכשל קבוע או לסירוגין.
3. בדוק את סטטוס הפריסה האחרון והאם שינוי אחרון בתלות, במשתנה סביבה, במסד נתונים או בשירות חיצוני תואם לתחילת הכשל.
4. לכוד שגיאות רלוונטיות ב-Console וב-Network.

אם הכשל נמשך, פנה לתמיכה עם שלבי שחזור, הגרסה המושפעת ואבחונים שעברו סניטיזציה. לפני שליחת HAR, פלט פקודה או צילום מסך, הסר קובצי Cookie, כותרות Authorization, אסימונים, פרמטרים סודיים בשאילתה, נתונים אישיים ופרטי תשלום.

אם הפריסה שלך פגה בזמן הקצוב או שהאתר החי אינו זמין זמנית:

1. בדוק אם גם תת-הדומיין Prod של הפלטפורמה וגם Preview אינם נגישים, או שרק אחד מהם.

2. השאר את דף השגיאה הנוכחי גלוי — אל תלחץ שוב ושוב על Publish.

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

אם הבעיה נמשכת, פנה לתמיכה וכלול:

- קישור לפרויקט וכתובת URL חיה

- זמן הכשל ואזור הזמן שלך

- מספר גרסה וצילום מסך של דף השגיאה

- האם Preview פועל כרגיל

- האם שינית לאחרונה תלויות, ערך הפעלה או חיבור למסד נתונים

אם חלונית הפרסום מציגה "latest" כשהכפתור אפור, או תקועה על "Building":

1. אל תלחץ שוב ושוב על Publish — זה לא יזרז את התהליך ועלול ליצור משימות build כפולות.

2. המתן כמה דקות ורענן את הדף.

3. אם הסטטוס לא משתנה לאחר הרענון, פנה לתמיכה.

כלול את הפרטים הבאים כשאתה פונה לתמיכה:

- קישור לצ'אט

- צילום מסך מלא של חלונית הפרסום (כולל כתובת ה-URL של הדף, מספר הגרסה ומצב הכפתור)

- זמן האירוע ואזור הזמן שלך

- מספר הגרסה המוצג כעת

- באיזה שלב התחיל להופיע "Building" או שהכפתור הפך לאפור

1. בדוק אם התמונה חסרה ב-App Viewer, באתר שפורסם, או בשני המקומות.
2. בחר Reload App Viewer פעם אחת. אם הבעיה קיימת רק באתר החי, ודא שהגרסה האחרונה פורסמה או עודכנה.
3. אמור ל-Agent מהו הדף, איזו תמונה אמורה להופיע, ומאיפה התמונה הגיעה במקור. בקש ממנו לבדוק שהפרויקט הנוכחי עדיין משתמש בשם התמונה ובמיקום הנכונים.
4. אם התמונה המקורית הוסרה או שונה שמה, העלה או בחר שוב את התמונה המיועדת, ואז בדוק מחדש את הדף.
5. אם התמונה משתמשת ב-App Storage או בשירות מחובר אחר, ודא שהשירות המיועד מחובר ושהקובץ עדיין קיים שם.

אם התמונה עדיין לא נטענת, פנה אל Atoms Support עם Chat Link, כתובת ה-URL של הדף המושפע, שם התמונה או המקור שלה, וצילום מסך. אל תכלול קישורי גישה פרטיים, סיסמאות, מפתחות או tokens.

אם חבילת ה-self-host שיוצאה יורדת בהצלחה אך לא מצליחה לפעול:

1. בדוק את קובץ ה-README הכלול בחבילת הייצוא לגבי דרישות הסביבה ושלבי ההגדרה.

2. ודא שסביבת הריצה שלך תואמת לדרישות (גרסת מערכת הפעלה, גרסת Docker, גרסת Node.js).

3. הרץ את פקודת ההפעלה ובדוק את הפלט המלא לאיתור הודעות שגיאה.

אם הבעיה נמשכת, פנה לתמיכה וכלול:

- גרסת הייצוא וזמן ההורדה

- מערכת ההפעלה שבשימוש וגרסת Docker

- הפקודה המלאה שבוצעה והפלט המלא

- סקריפט שנכשל או נתיב API

- שיטת הפריסה הצפויה

חשוב: צרף דוגמת תצורה לאחר השמטת מידע רגיש, אך אל תכלול סיסמאות, סודות או tokens.

App Viewer והאתר שפורסם מציגים שלבים שונים של הפרויקט שלך. שמירת שינוי חזותי לא מעדכנת את האתר החי בפני עצמה.

1. ב-Design, בחר Save והמתן עד שמשימת ה-Agent הנוכחית או ה-build יסתיימו.
2. פתח את Publish. הפרסום משתמש בגרסת הפרויקט העדכנית ביותר; אין בורר גרסאות בחלונית Publish.
3. בחר Publish עבור הפרסום הראשון או Update עבור פרסום מאוחר יותר. המתן עד שהחלונית תציג Up to date.
4. פתח את האתר החי בלשונית חדשה וטען אותו מחדש פעם אחת.
5. אם כתובת Atoms ברירת המחדל מציגה את השינוי אבל דומיין מותאם אישית לא, בדוק את חיבור הדומיין במקום לפרסם שוב ושוב את אותה גרסה.

אם האתר החי עדיין מציג את הגרסה השגויה, פנה אל תמיכת Atoms עם קישור הצ'אט, ה-URL החי, הגרסה שהתכוונת לפרסם, השעה ואזור הזמן, וצילומי מסך של App Viewer ושל האתר החי.

1. הכל את הסיכון המיידי. אם ההפצה חושפת נתונים רגישים או יוצרת התנהגות לא בטוחה, פתח את App Status והשתמש ב-Pause עבור אפליקציית Atoms Cloud זכאית או ב-Unpublish כדי להסיר גישה ציבורית. אם אין סיכון פעיל, הימנע מגרימת השבתה מיותרת.
2. תעד את הדומיין המושפע, זמן הפרסום, הגרסה הנוכחית, הגרסה המיועדת וההשפעה העסקית.
3. לאחר שמשימת הסוכן הנוכחית נעצרת, פתח את Versions, בחר את הגרסה האחרונה הידועה כתקינה, ובחר Restore this version.
4. אמת את הגרסה ששוחזרה ב-Preview, כולל תהליכי התחברות, תשלום ונתונים קריטיים, ואז פרסם או עדכן אותה.

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

1. עצור או המתן למשימת הסוכן הנוכחית; אי אפשר לשחזר גרסה בזמן שעבודה מתנגשת פעילה.
2. פתח את Versions, אתר את הגרסה האחרונה הידועה כתקינה, ובחר Restore this version.
3. בדוק את הפרויקט ששוחזר ב-Preview ובחן את התהליכים הקריטיים שהשתנו.
4. פרסם או עדכן רק לאחר שתוצאת ה-Preview נכונה.

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

Pause ו-Unpublish הן שתי פעולות שונות:

Pause (לפרויקטי Atoms Cloud בלבד):

- האפליקציה הופכת ללא זמינה למבקרים.

- משאבי השרת נשארים מוקצים והחיוב נמשך.

- אפשר לחדש את האפליקציה בכל עת מתוך App Status.

Unpublish (כל הפרויקטים):

- האתר יורד לגמרי מהאוויר. כל מי שמשתמש ב-URL שפורסם מאבד גישה.

- עבור פרויקטי Atoms Cloud, משאבי השרת משוחררים.

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

השתמש ב-Pause להסרה זמנית עם הפעלה מחדש מהירה. השתמש ב-Unpublish כדי להסיר את האתר לחלוטין.

אם הדפדפן שלך מציג "יותר מדי הפניות" או שהדף ממשיך להיטען מחדש בלי להציג תוכן:

1. נסה את תת-הדומיין ברירת המחדל של Prod בפלטפורמה (לא את הדומיין המותאם אישית שלך) כדי לקבוע אם לולאת ההפניה נגרמת מהגדרת הדומיין או מהאפליקציה עצמה.
2. אם תת-הדומיין ברירת המחדל של Prod עובד, בדוק את הגדרות ה-DNS של הדומיין המותאם אישית שלך ואת רשם הדומיינים שלך עבור כללי הפניה שעשויים להתנגש עם הפלטפורמה.
3. נקה את מטמון הדפדפן שלך או בדוק בחלון גלישה בסתר כדי לשלול הפניות אוטומטיות שנשמרו במטמון.

אם הבעיה נמשכת, פנה לתמיכה וצרף:

- כתובת URL מלאה שמציגה את לולאת ההפניה

- האם תת-הדומיין ברירת המחדל של Prod נגיש

- שם הדומיין וספק ה-DNS

- צילום מסך מלא של השגיאה

אם האפליקציה שלך עובדת ב-Preview אבל נכשלת בייצור בגלל משתני סביבה חסרים או ריקים:

1. בדוק אם משתנה הסביבה נשמר לפני או אחרי הפרסום האחרון. אם הוא נשמר אחרי, צריך לפרסם שוב כדי שהשינוי ייכנס לתוקף.
2. ודא שהמשתנה מוגדר עבור הסביבה הנכונה (Development לעומת Production).
3. בדוק אם הודעת השגיאה משירות ההמשך נותנת רמז — לדוגמה, "unauthorized" לעיתים קרובות אומר שמפתח API ריק או שגוי באותה סביבה.

אם הבעיה נמשכת, פנה לתמיכה וצרף:

- קישור לפרויקט או כתובת URL פעילה

- שם המפתח המושפע ובאיזו סביבה יש את הבעיה

- השגיאה המלאה מהשירות ההמשך

- צילום מסך מושחר של דף התצורה

- האם התצורה נשמרה לפני או אחרי הפרסום

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

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

1. השווה את שם הממצא ואת המיקום שמוצג עבור כל תוצאה.
2. בדוק כל מיקום ייחודי במקום לפסול את הניסוח החוזר.
3. אם לכמה ממצאים יש אותה סיבה בסיסית, תקן את הסיבה הזו ואז בדוק שוב כל מיקום.
4. הרץ שוב את סריקת האבטחה על הגרסה המעודכנת.

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

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

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

אם אתה מגלה בעיית ייצור שעלולה לחשוף חשבונות, נתונים פרטיים, תשלומים או פרטי גישה, הפסק תחילה להשתמש בתכונה המושפעת או הגבל את הגישה אליה. החלף כל פרט גישה שייתכן שנחשף, ואז פנה אל תמיכת Atoms עם קישור הצ'אט, הגרסה המושפעת, שלבים לשחזור הבעיה, הזמן ואזור הזמן, וצילום מסך מושחר. אל תשתף את פרט הגישה שנחשף עצמו.

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

1. פתחו את הממצא וזהו את הפעולה או המיקום שהוא מציין.
2. החליטו אילו תפקידים מחוברים צריכים להיות מורשים להשתמש בפעולה הזו.
3. בקשו מה-Agent לבדוק את ההרשאה של המשתמש כאשר הפעולה מתבקשת, ולא רק כאשר הכפתור מוצג.
4. בדקו את הפעולה כאשר אתם מנותקים, עם חשבון בדיקה רגיל, ועם חשבון בדיקה מורשה של מנהל.
5. אשרו שניסיונות שנדחו אינם חושפים נתונים פרטיים ואינם מבצעים שינויים, ואז הריצו שוב את סריקת האבטחה.

אל תפרסמו את היכולת המושפעת אם חשבון לא מורשה עדיין יכול להשתמש בפעולה. צרו קשר עם Atoms Support באמצעות Chat Link, טקסט הממצא, הגרסה המושפעת וצילום מסך מושחר אם אינכם יכולים לפתור זאת.

HTTPS מגן על מידע בזמן שהוא עובר בין משתמש לשירות. אם הסריקה מדווחת על בעיית HTTPS, השתמשו בממצא המדויק כדי לזהות את הכתובת, המשאב, ה-callback או תצורת הדומיין המושפעים.

1. פתחו את הממצא ורשמו את המיקום והכתובת המדויקים שהוא מדווח עליהם.
2. בקשו מה-Agent להחליף את החיבור הספציפי הזה בכתובת המאובטחת שנתמכת על ידי הספק שלו, או לתקן את תצורת הדומיין הקשורה.
3. אל תתעלמו מאזהרות אישור ואל תשנו כתובת באופן עיוור אם השירות החיצוני אינו מתעד חלופה מאובטחת.
4. בדקו מחדש את מסלול המשתמש המושפע ואשרו שלא נשלחים סיסמה, אסימון, פרטי תשלום או מידע פרטי דרך חיבור לא מאובטח.
5. הריצו שוב את סריקת האבטחה על הגרסה המעודכנת.

אם הממצא נוגע לדומיין מותאם אישית או לאישור שאינכם יכולים לתקן, צרו קשר עם Atoms Support באמצעות Chat Link, כתובת ה-URL המושפעת, טקסט הממצא, השעה ואזור הזמן, וצילום מסך מושחר.

Row Level Security, או RLS, היא תכונה של Supabase ששולטת באילו שורות במסד הנתונים כל משתמש יכול לקרוא או לשנות. הממצא הזה רלוונטי רק כאשר הפרויקט משתמש ב-Supabase והסריקה מזהה טבלה שכללי הגישה שלה דורשים בדיקה.

1. פתחו את הממצא וזהו את הטבלה שהוא מציין.
2. רשמו מי אמור להיות מסוגל לצפות בנתונים של הטבלה הזו, להוסיף אותם, לערוך אותם או למחוק אותם.
3. בקשו מה-Agent ליצור את מדיניות Supabase המגבילות ביותר האפשריות שתומכות במסלולי המשתמש האלה.
4. בדקו כאשר אתם מנותקים ועם חשבון בדיקה נפרד לכל תפקיד. אשרו שכל חשבון יכול לגשת רק לשורות ולפעולות המיועדות.
5. הריצו שוב את סריקת האבטחה לאחר שהמדיניות הוחלה.

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