יכול להיות שיהיה לכם קשה לפתור בעיות שקשורות לשגיאות אימות כשאתם משתמשים בהטמעה חתומה של תוכן Looker. יש כמה גישות שונות שאפשר לנסות כדי לאבחן בעיות, ותצטרכו לבחור גישה לפי המקום שאליו ההפניות האוטומטיות שולחות את המשתמשים. ההנחיות בדף הזה מניחות שאתם יוצרים את כתובת ה-URL החתומה להטמעה באמצעות סקריפט שדומה לסקריפטים במאגר הדוגמאות להטמעה ב-GitHub של Looker, אלא אם צוין אחרת.
דברים כלליים שכדאי לנסות קודם
לפני שמתחילים בהטמעה, צריך לוודא שסוד ההטמעה נוצר בחלונית Admin ושהתוכן המוטמע פועל במצב ייצור ולא רק במצב Development.
אם יש לכם הרשאות אדמין, תוכלו להשתמש בפקודה sudo בתור המשתמש שמשובץ כדי לבדוק שהתוכן פועל. אם מופיעה השגיאה Oops, we can't find that page, סביר להניח שהבעיה היא בהרשאות או בגישה לתוכן, ולא קשורה לבעיית אימות. אם המשתמש שמוטמע לא מופיע בדף Users בחלונית Admin של Looker, סימן שהמשתמש לא נוצר וכתובת ה-URL להטמעה נכשלת. אפשר לנסות לפתור את הבעיה באמצעות חלק מההצעות והמשאבים שמפורטים בדף הזה.
אם המופע שלכם מתארח באופן עצמאי, צריך לוודא ששרת הלקוח יכול להגיע לשרת Looker, ואם הנתונים בין הלקוח לשרת מועברים דרך האינטרנט הציבורי, צריך לוודא שנעשה שימוש ב-SSL (HTTPS).
בהמשך הדף מתוארות שגיאות ובעיות אחרות שבהן אתם עלולים להיתקל, ומוסבר איך לפתור אותן.
מופנית אוטומטית לדף כניסה או לדף 'כניסה יחידה נכשלה'
אם אתם מופנים לדף הכניסה או לדף עם השגיאה Single sign on failure. Please contact an adinistrator., בדרך כלל זה מצביע על כך שהאימות של ההטמעה עם החתימה לא פועל כמו שצריך.
קודם צריך ליצור כתובת URL חדשה להטמעה חתומה ולבדוק אותה בכלי לאימות URI של הטמעה בדף הטמעה בחלונית Admin של Looker. לפעמים, כלי האימות של URI להטמעה יכול לחשוף מידע חשוב לגבי הסיבה להופעת שגיאה.
האם הכלי לבדיקת תוקף של URI להטמעה מופיע כמו שציפיתם?
אם אתם נמצאים בדף Embed בחלונית Admin של Looker, והכלי Embed URI Validator לא מופיע בדף, סימן שהטמעת חתימה עדיין לא הופעלה. צריך להפעיל הטמעה עם חתימה.
מוצגת לי השגיאה 'signature param' failed to authenticate
אם השגיאה הזו מופיעה, החתימה שנוצרה על ידי הסקריפט לא פועלת כצפוי. אפשר לעיין בקטעים הבאים כדי למצוא פתרונות אפשריים:
האם הסודות של ההטמעה זהים?
הסוד להטמעה במכונה של Looker צריך להיות זהה לסוד להטמעה החתום בסקריפט ליצירת כתובת URL חתומה להטמעה. אם אתם לא בטוחים אם זה המצב, בוחרים באפשרות איפוס הסוד כדי ליצור סוד חדש ולהוסיף אותו לסקריפט. איפוס המפתח יגרום לשיבוש בכל ההטמעות שהשתמשו במפתח הקודם.
שימו לב: סודות שנוצרים באמצעות הדף הטמעה בחלונית אדמין נוצרים באמצעות האלגוריתם HMAC-SHA1. האלגוריתם שמוגדר כברירת מחדל לסיסמאות שנוצרות באמצעות נקודת קצה ל-API create_embed_secret הוא HMAC-SHA256. חשוב לוודא שתסריט ההטמעה משתמש באלגוריתם הנכון.
אפשר לנסות להשתמש בנקודת הקצהCreate Signed Embed Urlכדי ליצור את כתובת ה-URL להטמעה, ולציין את הסוד בתסריט עבורsecret_idבגוף הקריאה. בתשובה יצוין אם הסוד שבו אתם משתמשים לא תקין. שימוש בנקודת הקצה הזו גם מונע בעיות בסקריפטים שמשתמשים באלגוריתם חתימה שגוי.
האם מחרוזת החתימה מופיעה בסדר הנכון?
פרמטרים להטמעה במחרוזת החתימה חייבים להיות בסדר הנכון בסקריפט ליצירת כתובת ה-URL. הסדר הנכון מתועד בדף התיעוד בנושא הטמעה חתומה.
מחרוזת החתימה, כשהיא מודפסת, אמורה להיראות בערך כך לפני שהיא מקודדת:
company_name.looker.com
/login/embed/embed%2Fdashboards%2F123
"ac786cbc06162b1edde3a8b35920a93e"
15852443573600
"test_external_user_id"
["access_data","see_user_dashboards"]
["test_model"]
[]
"test group space"
{"test_user_attribute":"yes"}
{}
אחרי שחותמים על מחרוזת החתימה באמצעות הסוד להטמעה, מוודאים שהפרמטרים בכתובת ה-URL הסופית זהים לפרמטרים שצוינו במחרוזת החתימה. חשוב לוודא שתווים מיוחדים כמו + ו-/ מקודדים בפרמטרים של כתובת ה-URL (לדוגמה, המערכת עלולה לפרש את + כרווח אם הוא לא מקודד בצורה תקינה), ואין מעברי שורה בכתובת ה-URL החתומה להטמעה, כי יכול להיות שהם לא יזוהו אחרי הקידוד.
כדי לבדוק אם הסקריפט עובר את כל השלבים הנכונים ואם החתימה משתמשת בהצפנה הנכונה, אפשר להשוות את הסקריפט שלכם לדוגמאות לסקריפטים.
האם אתם משתמשים במופע שתומך בתקן FIPS?
אם מופעלת במכונת Looker שלכם תאימות ל-FIPS, יכול להיות שהיא תדחה חתימות שלא נוצרו באמצעות אלגוריתם שתואם ל-FIPS. מידע נוסף על מופעי Looker עם תמיכה ב-FIPS זמין בדפי התיעוד הבאים:
- הפעלת תאימות ל-FIPS 140-2 ברמה 1
- הפעלת תאימות לרמה 1 של FIPS 140-3 במופע של Looker (Google Cloud Core)
כשאתם משתמשים בסקריפט כדי ליצור כתובות URL חתומות להטמעה של אפליקציה שמוטמעת במופעים של Looker (Google Cloud core) עם תמיכה ב-FIPS, צריך להגדיר את סביבת המערכת בצד הלקוח (למשל Ruby, Python, Node.js וההתקנה המקומית של OpenSSL) בצורה מדויקת כך שתשתמש במודולים קריפטוגרפיים שתואמים ל-FIPS. אם הדרישות המקומיות האלה בנוגע להצפנה לא מתקיימות בסביבת המארח שיוצרת את כתובת ה-URL, החתימה שנוצרת תהיה לא תקינה, וכתוצאה מכך תופיע השגיאה 'signature' param failed to authenticate.
כדי להימנע מהמורכבות של הגדרת מודולים קריפטוגרפיים בצד הלקוח ואימות שלהם, צריך לעדכן את האפליקציה להטמעה כך שתשתמש בנקודת קצה ל-API של create_sso_embed_url כדי ליצור את כתובת ה-URL להטמעה. כשמבצעים קריאה ל-API באפליקציה להטמעה, צריך לציין סוד SHA-256 לפרמטר secret_id. כך ה-API יוצר הצפנה, במקום פונקציות קריפטוגרפיות מקומיות.
מוצגת לי השגיאה This request includes invalid params: ["embed_domain"]
לפני שמתחילים לפתור את הבעיה שגורמת לשגיאה הזו, חשוב לדעת שהפרמטר embed_domain נחוץ רק אם הסקריפט משתמש במאזיני אירועים של JavaScript, ובדרך כלל זה לא נדרש להטמעה בסיסית של הטמעה חתומה. אם האפליקציה לא צריכה להאזין לאירועי JavaScript, האפשרות הכי פשוטה היא להסיר את הפרמטר embed_domain לגמרי.
אם אתם צריכים להשתמש באירועי JavaScript באפליקציה המוטמעת, כדאי לבדוק את סקריפט יצירת כתובות ה-URL כדי לראות איפה נוסף הפרמטר embed_domain. בדרך כלל השגיאה הזו מצביעה על כך שהפרמטר embed_domain הוצב בטעות כפרמטר של הטמעה חתומה במקום ישירות בתוך embed_url. הסקריפט לא יפרמט את הפרמטר embed_domain בצורה נכונה אלא אם הוא באמת חלק מהפרמטר embed_url, והוא צריך להתווסף אחרי כתובת ה-URL להטמעה ולפני פרמטרים אחרים.
כך צריך להיראות התסריט כשהפרמטר embed_domain מצוין בצורה נכונה:
embed_url: "/embed/dashboards/3?embed_domain=https://company.com"
אם אתם משתמשים בנקודת הקצהCreate Signed Embed Url, צריך למקם את הפרמטרembed_domainבסוףtarget_url.
מוצגת לי השגיאה 'nonce' param already used this hour
הערך של הפרמטר nonce לא יכול לחזור על עצמו באותה שעה, והוא צריך להיות באורך של פחות מ-255 תווים. לכן, השגיאה הזו תופיע אם תבדקו כתובת URL שכבר הייתה אליה גישה. חשוב לוודא שאתם יוצרים כתובת URL חדשה להטמעה שלא נטענה עדיין בדפדפן, ושהערך של nonce משתנה ולא נעשה בו שימוש חוזר.
הופניתי לשגיאה Uh-Oh, Something went wrong
אם השגיאה הזו מופיעה, צריך לפנות אל התמיכה של Looker כדי לקבל עזרה באבחון הבעיה.
מופנית לדף עם הודעת השגיאה 401 You are not authenticated to view this page.
אם ניסיתם את כל השלבים הרלוונטיים לפתרון בעיות והבעיה 401 נמשכת, סביר להניח שהדפדפן חוסם קובצי Cookie של צדדים שלישיים. רוב הדפדפנים הופכים למגבילים יותר, וכברירת מחדל הם יפעלו לפי מדיניות קובצי Cookie שחוסמת את קובצי ה-Cookie האלה. לדוגמה, ההגדרה מניעת מעקב באתרים שונים ב-Safari מופעלת כברירת מחדל, וכך גם ההגדרה חסימת קובצי Cookie של צד שלישי במצב פרטי ב-Chrome.
אם האפליקציה שלכם מטמיעה תוכן של Looker ושם הדומיין של מופע Looker מסתיים ב-company.looker.com, הדפדפן לא יאמת את ה-iframe המוטמע בדומיינים שונים, אלא אם תשנו את הגדרות הפרטיות של קובצי ה-cookie בדפדפן.
מופעים שמתארחים ב-Looker
אדמינים של Looker בשרתים של Looker שלא רוצים שהמשתמשים שלהם יפעילו ידנית קובצי Cookie של צד שלישי בדפדפנים שלהם, יצטרכו לשנות את שם הדומיין של מופע Looker בשרתים של Looker. לדוגמה, מופעים שמתארחים ב-Looker בדרך כלל מקבלים את הפורמט https://<hostname>.<subdomain>.<domain>.com. אם שם הדומיין של Looker משתנה, Looker לא ייחשב יותר כדומיין של צד שלישי. מידע נוסף זמין בדף השיטות המומלצות בנושא איך לשנות את כתובת ה-URL של מופע Looker.
אם אתם רוצים להוסיף דומיין בהתאמה אישית למופע של Looker, אתם יכולים לפנות לתמיכה של Looker כדי להגדיר את תצורת ה-DNS הנדרשת.
מופעים באירוח עצמי
אם אתם מארחים בעצמכם את מופע Looker, אתם צריכים לוודא שהאפליקציה שמשתמשת בהטמעה חתומה נמצאת באותו דומיין בסיסי כמו מופע Looker. לשם כך, צריך לשנות את רשומות ה-DNS של מופע Looker.
ב-Chrome נדרש גם שכל קובץ Cookie זמני עם הדגל samesite=none יציין גם secure. Looker לא יציג את האות secure אם לא סופק למופע Looker --ssl-provided-externally-by=<s> דגל הפעלה, לכן חשוב לוודא שדגל ההפעלה הזה מוגדר.
הבעיה לא נפתרה. מה עושים עכשיו?
אם הבעיות נמשכות אחרי שניסיתם את ההצעות שבדף הזה, אפשר לפנות לאיש הקשר שלכם ב-Looker או להיכנס אל תמיכת Looker כדי לפתוח כרטיס תמיכה.