פתרון בעיות שקשורות לשגיאות 404

המדריך הזה יעזור לכם לפתור שגיאת 404 בדף אינטרנט של Looker או בבקשת Looker API. בדרך כלל, שגיאת 404 מציינת שהמשאב המבוקש לא קיים או שאין למשתמש הרשאה לגשת אליו.

עץ ניפוי הבאגים

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

בקטעים הבאים מפורטים התרחישים בעץ.

פתרון שגיאת 404 בדפדפן

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

בדיקה בלוח JavaScript

קודם כל, כדאי לבדוק את לוח JavaScript בדפדפן כדי לקבל מידע נוסף על השגיאה. כדי לפתוח את לוח Javascript ב-Google Chrome, פועלים לפי השלבים הבאים:

  1. לוחצים על תפריט האפשרויות הנוספות (3 נקודות).
  2. בוחרים באפשרות More Tools.
  3. לוחצים על Developer Tools.
  4. לוחצים על הכרטיסייה מסוף.

מחפשים את השגיאה 404 ברשימת השגיאות ומוצאים את כתובת ה-URL התואמת.

אם כתובת ה-URL שמחזירה 404 היא לא כתובת URL של Looker, השגיאה נובעת ממשאב חיצוני. אם כתובת ה-URL של הבקשה שייכת לאפליקציה בהתאמה אישית שמחוברת ל-Looker, צריך לבדוק את הקוד והיומנים של האפליקציה כדי לפתור את השגיאה. התמיכה של Looker בבעיות שקשורות למשאבים חיצוניים היא מוגבלת.

אם כתובת ה-URL היא כתובת URL של Looker, ממשיכים לקטע הבא.

בודקים אם יש שגיאות הקלדה בכתובת ה-URL

בודקים אם יש שגיאות הקלדה נפוצות בכתובת ה-URL. לדוגמה:

  • שגיאת כתיב נפוצה בשם של דף Look היא /look/123. התחביר הנכון הוא /looks/123.
  • שגיאת כתיב נפוצה לשם של דף מרכז הבקרה היא /dashboard/123. התחביר הנכון הוא /dashboards/123.

כשמצרפים קישור ל-Explore, לטבלת Look או ללוח בקרה ב-LookML, תמיד כדאי לבדוק קודם את הקישור כדי לוודא שהתחביר נכון.

אם מצאתם שגיאת הקלדה בקישור שנוצר מ-LookML, צריך לתקן את שגיאת ההקלדה ב-LookML. אם מצאתם שגיאת הקלדה בכתובת URL שנוצרה על ידי Looker (לדוגמה, ברכיב ניווט בממשק המשתמש), צריך לפנות לתמיכה כדי לבקש לתקן את כתובת ה-URL במוצר.

פתרון בעיות שגיאה 404 ב-API

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

בדיקת מאמרי העזרה של נקודת קצה ל-API

צריך לעיין במסמכי התיעוד של נקודת הקצה (endpoint) של ה-API שמחזירה את שגיאת 404. לדוגמה, דף התיעוד של נקודת הקצה create_sso_embed_url הוא Create Signed Embed URL. צריך לבדוק את הפרמטרים ולוודא שאתם מספקים את הפרמטרים הנכונים לקריאה ל-API.

מוודאים שפועל הבקשה והנתיב נכונים. לדוגמה, צריך להשתמש בנקודת הקצה /api/4.0/embed/sso_url עם הפועל POST.

אפשר גם לבדוק את נקודת קצה ל-API ישירות במופע באמצעות API Explorer.

בדיקה של התנאים הנדרשים לנקודת קצה

חלק מנקודות הקצה זמינות רק בתנאים מסוימים:

  • חלק מנקודות הקצה של פרויקט של LookML (כמו create_project,‏ deploy_to_production ו-reset_project_to_production) זמינות רק במצב פיתוח.
    • במקרה הצורך, משתמשים בנקודת הקצה update_session עם גוף הבקשה {"workspace_id": "dev"} כדי להעביר את סשן ה-API למצב פיתוח.
  • נקודת הקצה reset_project_to_production לא זמינה בענפים משותפים.
  • נקודת הקצה deploy_ref_to_production זמינה רק אם מופעל מצב פריסה מתקדם.

בדיקת ההגדרות של תגובה לפעולה מאתר אחר (Webhook)

אם כתובת ה-URL של הבקשה היא webhook לפריסה, צריך לבדוק את הגדרות ה-webhook.

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

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

בדיקה אם המשאבים המבוקשים קיימים

מוודאים שכל המשאבים שההפניה אליהם מופיעה בבקשה אכן קיימים במופע Looker.

צריך לוודא שכל הערכים בכתובת ה-URL ובגוף הבקשה (למשל מזהי תיקיות או מזהי לוחות בקרה) מתייחסים למשאבים קיימים ותקינים. לדוגמה, כדי לבדוק אם לוח בקרה קיים, צריך לעבור אל /dashboards/[id] כמשתמש עם הרשאת אדמין. אם משאב חסר או לא תקין, צריך ליצור את המשאב החסר או לציין משאב קיים.

אם המשאב קיים אבל עדיין מתקבלת שגיאת 404, צריך לבדוק אם המשאב קיים במצב פיתוח. אם למשתמש Looker יש הרשאת develop, צריך לבדוק אם המשתמש יכול לגשת למשאב כשהוא נכנס למצב פיתוח. לקריאות API, צריך להשתמש בנקודת הקצה update_session עם גוף הבקשה {"workspace_id": "dev"} כדי להעביר את סשן ה-API למצב פיתוח.

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

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

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

מתחזים למשתמש ובודקים אם השגיאה מופיעה

אדמינים יכולים לעבור לחלונית Admin > Users (אדמין > משתמשים) ולהתחזות למשתמש שנתקל בשגיאה 404 (sudo).

  • אם המשתמש הוא משתמש בהטמעה, צריך לוודא שהאישורים להטמעה שלו בדף אדמין > משתמשים זהים לערך external_user_id בכתובת ה-URL להתחברות להטמעה.
  • אם המשתמש מבצע קריאה ל-API, משתמשים בנקודת הקצה login_user כדי להתחזות למשתמש.

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

בדיקה של ההרשאות הנדרשות

כדי לוודא שלמשתמש יש את ההרשאות הנדרשות לפחות באחד מהתפקידים שלו, בודקים את התפקידים של המשתמש בחלונית אדמין > משתמשים ואת רשימת ההרשאות ב-Looker. לדוגמה, כדי לצפות בלוח בקרה, למשתמש צריכות להיות לפחות ההרשאות access data, see_looks ו-see_user_dashboards. אם למשתמש חסרות ההרשאות הנדרשות, מוסיפים את ההרשאות האלה לקבוצת הרשאות בתפקיד שמוקצה למשתמש.

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

בדיקה של הרשאות הטמעה תקינות

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

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

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

בדיקת הגישה לתוכן

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

בדיקה סופית ותמיכה

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