הטמעת פתרון זהויות באמצעות FedCM בצד של הצד הנסמך

צדדים מסתמכים (RP) צריכים לבצע את השלבים הבאים כדי להפעיל FedCM באתר שלהם:

• מוודאים שנקודות הקצה של FedCM מורשות באתר של ספק הזהויות.
• משתמשים ב-FedCM JavaScript API כדי להתחיל את אימות המשתמש.
• מספקים את המטא-נתונים שלהם (כמו כתובות URL של מדיניות הפרטיות והתנאים וההגבלות) לספק הזהויות (או למספר ספקי זהויות מ-Chrome 136).
• [אופציונלי] אפשר להתאים אישית את חוויית המשתמש על ידי בחירה של מצב חוויית משתמש, הזנה של רמזים להתחברות או רמזים לדומיין, העברה של פרמטרים מותאמים אישית, בקשה של פרטי משתמש ספציפיים, הזנה של הודעת שגיאה מותאמת אישית או בחירה של האופן שבו המשתמשים יאומתו מחדש.

שליחת קריאה ל-FedCM API ב-Relying Party

אחרי שההגדרות של ספק ה-IdP ונקודות הקצה שלו זמינות, צדדים מסתמכים יכולים להפעיל את navigator.credentials.get() כדי לבקש לאפשר למשתמש להיכנס לצד המסתמך באמצעות ספק ה-IdP.

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

  if ('IdentityCredential' in window) {
    // If the feature is available, take action
  } else {
    // FedCM is not supported, use a different identity solution
  }

כדי לאפשר למשתמש להיכנס לספק הזהויות ב-RP באמצעות FedCM, ה-RP יכול להתקשר אל navigator.credentials.get(). החל מ-Chrome 136, ספק שירות יכול לתמוך בכמה ספקי זהויות על ידי ציון מערך של כמה ספקי זהויות בקריאה אחת של navigator.credentials.get(), לדוגמה:

  const credential = await navigator.credentials.get({
      identity: {
        // Specify the IdP (or multiple IdPs, supported from Chrome 136) this Relying Party supports
        providers: [
        {
              configURL: 'https://accounts.idp-1.example/config.json',
              clientId: '********'
        },
        {
          configURL: 'https://accounts.idp-2.example/config.json',
          clientId: '********'
        }]
      }
    },
  );
  const { token } = credential;
  
  // Get the current IdP's configURL to identify which provider the user is signed in with
  const currentIdpConfigUrl = credential.configURL;
  if (currentIdpConfigUrl === 'https://idp1.example/foo.json') {
    // handle the case where the user signed in with idp1
  } else if (currentIdpConfigUrl === 'https://idp2.example/bar.json') {
    // handle the case where the user signed in with idp2
    }

כדי לנסות את התכונה של כמה ספקי IdP, צריך להיכנס באמצעות IdP1 ו-IdP2.

מאפיין הקשר

באמצעות המאפיין האופציונלי context, ה-RP יכול לשנות את המחרוזת בממשק המשתמש של תיבת הדו-שיח של FedCM (לדוגמה, 'כניסה אל rp.example…', 'שימוש ב-idp.example…') כדי להתאים להקשרים מוגדרים מראש של אימות, למשל. המאפיין context יכול לקבל את הערכים הבאים:

• ‫signin (ברירת מחדל)
• signup
• use

לדוגמה, אם מגדירים את context ל-use, תוצג ההודעה הבאה:

הדפדפן מטפל בתרחישי שימוש של הרשמה וכניסה בצורה שונה, בהתאם לקיום של approved_clients בתגובה מנקודת הקצה של רשימת החשבונות. אם המשתמש כבר נרשם ל-RP, בדפדפן לא יוצג טקסט גילוי נאות "כדי להמשיך עם...".
המאפיין providers מקבל מערך של אובייקטים מסוג IdentityProvider עם המאפיינים הבאים:

מאפיין הספקים

המאפיין providers מקבל מערך של אובייקטים מסוג IdentityProvider עם המאפיינים הבאים:

מצב פעיל

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

כדי להשתמש ב-FedCM במצב פעיל:

1. בודקים את זמינות התכונה בדפדפן של המשתמש.
2. מפעילים את ה-API באמצעות תנועת משתמש חולפת, כמו לחיצה על כפתור.
3. מעבירים את הפרמטר mode לקריאה ל-API:

  let supportsFedCmMode = false;
  try {
    navigator.credentials.get({
      identity: Object.defineProperty(
        // Check if this Chrome version supports the Mode API.
        {}, 'mode', {
          get: function () { supportsFedCmMode = true; }
        }
      )
    });
  } catch(e) {}

  if (supportsFedCmMode) {
    // The button mode is supported. Call the API with mode property:
    return await navigator.credentials.get({
      identity: {
        providers: [{
          configURL: 'https://idp.example/config.json',
          clientId: '123',
        }],
        // The 'mode' value defines the UX mode of FedCM.
        // - 'active': Must be initiated by user interaction (e.g., clicking a button).
        // - 'passive': Can be initiated without direct user interaction.
        mode: 'active'
      }
    });
  }

כאן אפשר לנסות את המצב הפעיל.

סמל מותאם אישית במצב פעיל

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

קריאה ל-FedCM מתוך iframe חוצה-מקורות

אפשר להפעיל את FedCM מתוך iframe חוצה מקור באמצעות מדיניות הרשאות identity-credentials-get, אם מסגרת ההורה מאפשרת זאת. כדי לעשות זאת, מוסיפים את המאפיין allow="identity-credentials-get" לתג ה-iframe באופן הבא:

  <iframe src="https://fedcm-cross-origin-iframe.glitch.me" allow="identity-credentials-get"></iframe>

דוגמה

אופציונלי: אם הפריים הראשי רוצה להגביל את המקורות לקריאה ל-FedCM, הוא צריך לשלוח כותרת Permissions-Policy עם רשימה של מקורות מורשים.

  Permissions-Policy: identity-credentials-get=(self "https://fedcm-cross-origin-iframe.glitch.me")

מידע נוסף על אופן הפעולה של מדיניות ההרשאות זמין במאמר שליטה בתכונות של הדפדפן באמצעות מדיניות ההרשאות.

Login Hint API

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

ספקי זהויות יכולים להציג חשבון ספציפי באופן סלקטיבי על ידי הפעלת navigator.credentials.get() עם המאפיין loginHint ואחד מהערכים login_hints שאוחזרו מנקודת הקצה של רשימת החשבונות, כמו שמוצג בדוגמת הקוד הבאה:

  return await navigator.credentials.get({
    identity: {
      providers: [{
        configURL: 'https://idp.example/manifest.json',
        clientId: '123',
        // Accounts endpoint can specify a 'login_hints' array for an account.
        // When RP specifies a 'exampleHint' value, only those accounts will be
        // shown to the user whose 'login_hints' array contains the 'exampleHint'
        // value
        loginHint : 'exampleHint'
      }]
    }
  });

אם אין חשבונות שתואמים ל-loginHint, מוצגת תיבת דו-שיח של FedCM עם הנחיה להתחברות, שמאפשרת למשתמש להתחבר לחשבון בספק הזהויות שתואם לרמז שביקש ה-RP. כשהמשתמש מקיש על ההנחיה, נפתח חלון קופץ עם כתובת ה-URL להתחברות שצוינה בקובץ ההגדרות. לאחר מכן, הפרמטרים של מחרוזת השאילתה login_hint ו-domain_hint מצורפים לקישור.

Domain Hint API

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

כדי להציג רק חשבונות של דומיין ספציפי, RP צריך לבצע קריאה ל-navigator.credentials.get() עם המאפיין domainHint ואחד מהערכים domain_hints שאוחזרו מנקודת הקצה של רשימת החשבונות, כמו שמוצג בדוגמת הקוד הבאה:

  return await navigator.credentials.get({
    identity: {
      providers: [{
        configURL: 'https://idp.example/manifest.json',
        clientId: 'abc',
        // Accounts endpoint can specify a 'domain_hints' array for an account.
        // When RP specifies a '@domain.example' value, only those accounts will be
        // shown to the user whose 'domain_hints' array contains the
        // '@domain.example' value
        domainHint : '@domain.example'
      }]
    }
  });

אם אין חשבונות שתואמים ל-domainHint, מוצגת תיבת דו-שיח של FedCM עם הנחיה להתחברות, שמאפשרת למשתמש להתחבר לחשבון בספק הזהויות שתואם לרמז שביקש ה-RP. כשהמשתמש מקיש על ההנחיה, נפתח חלון קופץ עם כתובת ה-URL להתחברות שצוינה בקובץ ההגדרות. לאחר מכן, הפרמטרים של מחרוזת השאילתה login_hint ו-domain_hint מצורפים לקישור.

פרטים נוספים זמינים בהדגמה.

פרמטרים מותאמים אישית

התכונה 'פרמטרים מותאמים אישית' מאפשרת לספק פרמטרים נוספים של צמדי מפתח/ערך לנקודת הקצה של הצהרת הזהות. בעזרת Parameters API, ספקי RP יכולים להעביר פרמטרים נוספים לספק ה-IdP כדי לבקש הרשאות למשאבים מעבר לכניסה בסיסית. העברת פרמטרים נוספים יכולה להיות שימושית בתרחישים הבאים:

• ספק ה-RP צריך לבקש באופן דינמי הרשאות נוספות שיש לספק ה-IdP, כמו גישה לכתובת לחיוב או ליומן. המשתמש יכול לאשר את ההרשאות האלה באמצעות תהליך UX מבוקר על ידי IdP שמופעל באמצעות התכונה 'המשך', ואז ה-IdP ישתף את המידע הזה.

כדי להשתמש ב-API, ספק הזהות מוסיף פרמטרים לנכס params כאובייקט בקריאה navigator.credentials.get():

  let {token} = await navigator.credentials.get({
    identity: {
      providers: [{
        clientId: '1234',
        configURL: 'https://idp.example/fedcm.json',
        // Key/value pairs that need to be passed from the
        // RP to the IdP but that don't really play any role with
        // the browser.
        params: {
          IDP_SPECIFIC_PARAM: '1',
          foo: 'BAR'
        }
      },
    }
  });

הדפדפן יתרגם את זה אוטומטית לבקשת POST ל-IdP עם פרמטרים כאובייקט יחיד שעבר סריאליזציה ל-JSON עם קידוד כתובת URL:

  // The assertion endpoint is drawn from the config file
  POST /fedcm_assertion_endpoint HTTP/1.1
  Host: idp.example
  Origin: https://rp.example/
  Content-Type: application/x-www-form-urlencoded
  Cookie: 0x23223
  Sec-Fetch-Dest: webidentity

  // params are translated into urlencoded version of `{"IDP_SPECIFIC_PARAM":"1","foo":"bar"}`
  account_id=123&client_id=client1234&params=%22%7B%5C%22IDP_SPECIFIC_PARAM%5C%22%3A1%2C%5C%22foo%5C%22%3A%5C%22BAR%5C%22%7D%22.

אם ספק השירות צריך הרשאות נוספות, ספק הזהויות יכול לספק קישור להפניה אוטומטית. לדוגמה, ב-node.js:

  if (rpRequestsPermissions) {
    // Response with a URL if the RP requests additional permissions
    return res.json({
      continue_on: '/example-redirect',
    });
  }

שדות

ספק השירות יכול לציין את פרטי המשתמש (כל שילוב של שם, כתובת אימייל ותמונת פרופיל) שהוא צריך שספק הזהויות ישתף איתו. המידע המבוקש ייכלל בממשק המשתמש של הגילוי הנאות בתיבת הדו-שיח של FedCM. אם המשתמש יבחר להיכנס לחשבון, תוצג לו הודעה שלפיה idp.example ישתף את המידע המבוקש עם rp.example.

כדי להשתמש בתכונה Fields, צריך להוסיף מערך fields בקריאה navigator.credentials.get(). השדות יכולים להכיל כל פרמוטציה של name, email ו-picture. יכול להיות שבעתיד נרחיב את האפשרויות האלה ונוסיף עוד ערכים. בקשה עם fields תיראה כך:

  let { token } = await navigator.credentials.get({
    identity: {
      providers: [{
        // RP requests the IdP to share only user email and profile picture
        fields: [ 'email', 'picture'],
        clientId: '1234',
        configURL: 'https://idp.example/fedcm.json',

      },
    }
  });

הדפדפן יתרגם את הבקשה באופן אוטומטי לבקשת HTTP לנקודת הקצה של הצהרת הזהות, שתכלול את הפרמטר fields שצוין על ידי ספק השירות, עם השדות שהדפדפן חשף למשתמש בפרמטר disclosure_shown_for. לצורך תאימות לאחור, הדפדפן ישלח גם את הערך disclosure_text_shown=true אם טקסט הגילוי הנאות הוצג והשדות המבוקשים כוללים את כל שלושת השדות: 'name',‏ 'email' ו-'picture'.

  POST /id_assertion_endpoint HTTP/1.1
  Host: idp.example
  Origin: https://rp.example/
  Content-Type: application/x-www-form-urlencoded
  Cookie: 0x23223
  Sec-Fetch-Dest: webidentity

  // The RP only requested to share email and picture. The browser will send `disclosure_text_shown=false`, as the 'name' field value is missing
  account_id=123&client_id=client1234&disclosure_text_shown=false&fields=email,picture&disclosure_shown_for=email,picture

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

זה קורה גם אם התגובה מנקודת הקצה של החשבונות לא מכילה מזהה לקוח שתואם ל-RP ב-approved_clients.

במקרה הזה, הערך של disclosure_text_shown שנשלח אל נקודת הקצה של הצהרת הזהות הוא false בגוף ה-HTTP:

  POST /id_assertion_endpoint HTTP/1.1
  Host: idp.example
  Origin: https://rp.example/
  Content-Type: application/x-www-form-urlencoded
  Cookie: 0x23223
  Sec-Fetch-Dest: webidentity

  account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false

הצגת הודעת שגיאה

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

  try {
    const cred = await navigator.credentials.get({
      identity: {
        providers: [
          {
            configURL: 'https://idp.example/manifest.json',
            clientId: '1234',
          },
        ],
      }
    });
  } catch (e) {
    const code = e.code;
    const url = e.url;
  }

אימות מחדש אוטומטי של משתמשים אחרי האימות הראשוני

אימות מחדש אוטומטי באמצעות FedCM (בקיצור: auto-reauthn) מאפשר למשתמשים לבצע אימות מחדש באופן אוטומטי. התנאים הבאים צריכים להתקיים כדי שהמשתמש יאומת מחדש באופן אוטומטי:

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

חוויית המשתמש הברורה הזו הגיונית לפני שהמשתמש יוצר את החשבון המאוחד כדי למנוע מעקב (אחת המטרות העיקריות של FedCM), אבל היא מסורבלת שלא לצורך אחרי שהמשתמש כבר עבר אותה פעם אחת: אחרי שהמשתמש מעניק הרשאה לאפשר תקשורת בין ה-RP לבין ספק הזהויות, אין יתרון לפרטיות או לאבטחה באכיפה של אישור משתמש ברור נוסף למשהו שהוא כבר אישר בעבר.

באימות מחדש אוטומטי, ההתנהגות של הדפדפן משתנה בהתאם לאפשרות שמציינים עבור mediation כשמפעילים את navigator.credentials.get().

  const cred = await navigator.credentials.get({
    identity: {
      providers: [{
        configURL: 'https://idp.example/fedcm.json',
        clientId: '1234',
      }],
    },
    mediation: 'optional', // this is the default
  });

  // `isAutoSelected` is `true` if auto-reauthn was performed.
  const isAutoSelected = cred.isAutoSelected;

‫mediation הוא מאפיין ב-Credential Management API. הוא מתנהג באותו אופן כמו במקרים של PasswordCredential ו-FederatedCredential, ויש לו תמיכה חלקית גם ב-PublicKeyCredential. המאפיין מקבל את ארבעת הערכים הבאים:

• ‫'optional'(ברירת מחדל): אימות מחדש אוטומטי אם אפשר, נדרשת תיווך אם לא. מומלץ לבחור באפשרות הזו בדף הכניסה.
• ‫'required': תמיד נדרש תהליך גישור כדי להמשיך, למשל, לחיצה על הלחצן 'המשך' בממשק המשתמש. בוחרים באפשרות הזו אם מצפים מהמשתמשים להעניק הרשאה במפורש בכל פעם שהם צריכים לעבור אימות.
• ‫'silent': אימות מחדש אוטומטי אם אפשר, או כשל שקט בלי לדרוש תהליך בחירת רשת אם אי אפשר. מומלץ לבחור באפשרות הזו בדפים שאינם דף הכניסה הייעודי, אבל שבהם רוצים שהמשתמשים יישארו מחוברים – למשל, דף פריט באתר משלוחים או דף כתבה באתר חדשות.
• ‫'conditional': משמש ל-WebAuthn ולא זמין ל-FedCM בשלב הזה.

בשיחה הזו, אימות מחדש אוטומטי מתבצע בתנאים הבאים:

• אפשר להשתמש ב-FedCM. לדוגמה, המשתמש לא השבית את FedCM באופן גלובלי או עבור ה-RP בהגדרות.
• המשתמש השתמש רק בחשבון אחד עם FedCM API כדי להיכנס לאתר בדפדפן הזה.
• המשתמש מחובר לספק הזהות באמצעות החשבון הזה.
• האימות מחדש האוטומטי לא התבצע ב-10 הדקות האחרונות.
• ספק הזהויות לא התקשר אל navigator.credentials.preventSilentAccess() אחרי הכניסה הקודמת.

כשמתקיימים התנאים האלה, מתחיל ניסיון לאימות מחדש של המשתמש באופן אוטומטי ברגע שמפעילים את FedCM navigator.credentials.get().

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

המידע הזה עוזר להעריך את הביצועים של ה-API ולשפר את חוויית המשתמש בהתאם. בנוסף, כשהאפשרות הזו לא זמינה, יכול להיות שהמשתמש יתבקש להיכנס באמצעות תהליך מפורש של תיווך משתמש, שהוא תהליך עם mediation: required.

החלת בחירת רשת באמצעות preventSilentAccess()

אימות מחדש אוטומטי של משתמשים מיד אחרי שהם יוצאים מהחשבון לא יספק חוויית משתמש טובה. לכן, ב-FedCM יש תקופת שקט של 10 דקות אחרי אימות מחדש אוטומטי, כדי למנוע את ההתנהגות הזו. המשמעות היא שהאימות מחדש האוטומטי מתבצע פעם אחת לכל היותר בכל 10 דקות, אלא אם המשתמש נכנס שוב לחשבון תוך 10 דקות. ספק הזהויות צריך לקרוא לפונקציה navigator.credentials.preventSilentAccess() כדי לבקש באופן מפורש מהדפדפן להשבית את האימות מחדש האוטומטי כשמשתמש יוצא מהחשבון בספק הזהויות באופן מפורש, למשל על ידי לחיצה על לחצן יציאה מהחשבון.

  function signout() {
    navigator.credentials.preventSilentAccess();
    location.href = '/signout';
  }

המשתמשים יכולים לבטל את ההסכמה לאימות מחדש אוטומטי בהגדרות

המשתמשים יכולים להשבית את האימות מחדש האוטומטי בתפריט ההגדרות:

• ב-Chrome במחשב, עוברים אל chrome://password-manager/settings > כניסה אוטומטית.
• ב-Chrome ל-Android, פותחים את ההגדרות > מנהל הסיסמאות > מקישים על סמל גלגל השיניים בפינה השמאלית העליונה > כניסה אוטומטית.

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

ניתוק ספק הזהויות מספק השירות

אם משתמש נכנס בעבר ל-RP באמצעות ספק הזהויות דרך FedCM, הדפדפן שומר את הקשר הזה באופן מקומי כרשימה של חשבונות מקושרים. ספק ה-RP יכול ליזום ניתוק על ידי הפעלת הפונקציה IdentityCredential.disconnect(). אפשר להפעיל את הפונקציה הזו מתוך מסגרת RP ברמה העליונה. כדי לנתק את ספק הזהויות, על ספק הזהויות להעביר configURL, את clientId שבו הוא משתמש במסגרת ספק הזהויות וaccountHint. רמז לגבי החשבון יכול להיות מחרוזת שרירותית, כל עוד נקודת הקצה לניתוק יכולה לזהות את החשבון. לדוגמה, כתובת אימייל או מזהה משתמש שלא בהכרח תואמים למזהה החשבון שסופק על ידי נקודת הקצה של רשימת החשבונות:

  // Disconnect an IdP account 'account456' from the RP 'https://idp.com/'. This is invoked on the RP domain.
  IdentityCredential.disconnect({
    configURL: 'https://idp.com/config.json',
    clientId: 'rp123',
    accountHint: 'account456'
  });

הפונקציה IdentityCredential.disconnect() מחזירה Promise. יכול להיות שההבטחה הזו תזרוק חריגה מהסיבות הבאות:

• המשתמש לא נכנס לאתר (Relying Party) באמצעות ספק הזהויות דרך FedCM.
• הפעלת ה-API מתבצעת מתוך iframe ללא מדיניות הרשאות של FedCM.
• הערך של configURL לא תקין או שנקודת הקצה של הניתוק חסרה.
• בדיקת Content Security Policy‏ (CSP) נכשלת.
• יש בקשת ניתוק בהמתנה.
• המשתמש השבית את FedCM בהגדרות הדפדפן.

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

השלבים הבאים

הטמעת FedCM בצד ה-IdP

איך מטמיעים את פתרון הזהויות באמצעות FedCM בצד של ספק הזהויות

התאמה אישית וביטול הסכמה

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