הגדרת CPID

ב-GTAF משתמשים במפתח משתמש כדי לזהות מנוי בחלק של התקשורת עם הרשות להגנה על מידע (DPA). אפליקציות עם גישה ל- MSISDN של המשתמש יכולות להשתמש בו כ-user_key. מצד שני, לאפליקציות שאין להן גישה ל-MSISDN, צריך להגדיר מזהה תוכנית ספק (CPID) בלי לגלות את MSISDN של המשתמש. בקטע הבא נתאר את המנגנון ליצירת CPID.

תהליך שיחה לפי עלות ליום

איור 2: זרימת שיחה ליצירת CPID.

1. אפליקציה של Google ב-UE משתמשת ב-API פנימי של Google כדי לאחזר את כתובת ה-URL של נקודת הקצה של CPID מ-GTAF. המערכת מזהה את המפעיל באמצעות כתובת ה-IP הציבורית של הלקוח וב-MCC ו-MNC של כרטיס ה-SIM הפעיל. במקרה של MVNO, Google תשתמש ב-SPN וב-GID1 כדי לקבוע את ה-MVNO
2. הלקוח שולח בקשת GET של HTTP לנקודת הקצה (CPID). האופרטור עשוי לתמוך בשליחת הבקשה באמצעות HTTPS.
3. האופרטור MAY משתמש בפונקציית הבדיקה של חבילות העומק כדי לזהות את הבקשה, ולהחדיר את מספר הטלפון של המשתמש לבקשה ככותרת HTTP.
4. נקודת הקצה (CPID) מקבלת את הבקשה, יוצרת את ה-CPID ומחזירה את ה-CPID עם משך החיים (TTL), כדי לציין את משך הזמן שבו ה-UE יכול להשתמש ב-CPID הזה.

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

האופרטור SHALL יספק ל-Google את הפרטים הבאים כחלק מתהליך ההצטרפות:

1. ה-CPID_URL שאליו אפליקציות ייצרו קשר כדי להשיג CPID. אחת מהכתובות CPID_URL היא חובה, אבל המפעיל יכול לספק כמה כתובות URL כדי להגדיל את הזמינות.
2. רשימת הקידומות של כתובת ה-IP של המפעיל והקוד של המדינה לנייד (MCC) וקודי הרשתות לנייד (MNC) שהמפעיל רוצה למפות למפות ה-CPID_URLs שסופקו. אם האופרטור משתמש ב-SPN או ב-GID1 כדי להבדיל בין MVNO ברשת, האופרטור SHALL מספק גם את המידע הזה. Google תשתמש במידע הזה כדי להתאים בין לקוחות לבין נקודות הקצה התואמות של CPID, כפי שמתואר בשלב 1 באיור 2.

הפורמט של הבקשה הוא: GET CPID_URL מסיבות קודמות, נקודת הקצה של CPID צריכה לתמוך בבקשה כמו:

GET CPID_URL?app={app_id}

בנקודת הקצה של CPID, אפשר להתעלם מהפרמטר {app_id} של כתובת URL בעת יצירת ה-CPID. עם זאת, עליו לטפל בבקשה שמכילה את הפרמטר.

הבקשה לנקודת הקצה CPID עשויה לכלול כותרת Accept-Language. אם הכותרת כוללת את המחרוזות הניתנות לקריאה אנושית בעדכונים שה-DPA שולח באמצעות Mobile Data Plan Sharing API, חובה להשתמש בהגדרות שסופקו בבקשת ה-CPID.

בכל פעם שהלקוח שולח בקשת CPID_URL, הוא חייב לקבל CPID חדש. אם יצירת ה-CPID הושלמה, נקודת הקצה של CPID חייבת להחזיר תגובה של 200. תוכן התגובה חייב להכיל מופע של CPIDResponse.

{
    "cpid": "<CPID_string>",
    "ttlSeconds": 2592000
}

ה-CPID המוחזר חייב להיות תקף ל-ttlשניות, גם אם מנוי ביקש CPID אחר לאחר מכן. Google ממליצה להשתמש בערך TTL של 30 יום, אבל לא פחות מ-14 ימים, כדי ליהנות מחוויית המשתמש הטובה ביותר. GTAF מקודד את ה-CPID ב-RFC2396 בקריאות הבאות ל-DPA.

יצירת CPID

הדרך המומלצת בנקודת הקצה של CPID ליצירת CPID היא:

CPID_string = Base64(AES(MSISDN + TimeStamp + language, secret))

נקודת הקצה (CPID) תואמת את MSISDN, השפה שנשלחה על ידי הלקוח בכותרת Get-Language, וחותמת זמן של רזולוציה גבוהה ומצפינה אותה באמצעות AES באמצעות מפתח secret. חותמת הזמן צריכה להיות תואמת למועד שבו תוקף ה-CPID יפוג. הפלט המוצפן מקודד לפי Base64. כמו כן, כשמשתמשים ב-CPID בכתובת ה-URL, צריך לקודד את כתובת ה-URL לטיפול בתווים מיוחדים (/+=) שנמצאים ב-Base64. באופן ספציפי, כשה-GTAF מתקשר ל-DPA או כשה-DPA מתקשר ל-Mobile Data Plan API API, קוד ה-CPID חייב להיות מקודד בכתובת ה-URL.

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

אחסון CPID

אין צורך לשמור במסד נתונים את ה-CPID שנוצר באמצעות המנגנון שתואר למעלה. אפשר לאסוף מידע רלוונטי על טיפול בקריאות להגנה על מידע (DPA) מה-CPID.

1. כשה-DPA מקבל שיחה מ-GTAF עם סטטוס של תוכנית או הצעות, אפשר להסיק את ה-MSISDN על ידי פענוח ה-CPID ושליפת ה-MSISNDN.
2. אפשר להסיק את זמן התפוגה של ה-CPID על ידי פענוח ה-CPID, ולאחר מכן העברה של חותמת הזמן לפקיעת התוקף.

דרישות זמינות וקיבולת

אם הלקוחות לא יכולים לאחזר CPID, הם לא יכולים לגשת למידע מ-Mobile Data Plan API. לכן, האופרטור ינקוט את האמצעים הנדרשים כדי להבטיח את הזמינות של נקודת הקצה של CPID. האמצעים האלה כוללים ריבוי מופעים של נקודות הקצה של CPID ו-DPI, יתירות פיזית, אתר ורשת בשתי הפונקציות והקפדה על כך שהמשאבים והקיבולת של המערכת יהיו מספיקים. מעבר לכך, לנקודות הקצה של CPID ולפונקציה DPI שמכניסת את הכותרת צריכה להיות קיבולת מספקת כדי להתמודד עם העומס על כל לקוחות Google שמבקשים מספרי CPID. נקודת הקצה (CPID) יכולה להשתמש בערכים גדולים יותר בשדה ttlSeconds כדי להפחית את התדירות שבה נוצרים CPID.

מקרי שגיאה

אם מתרחשת שגיאה, נקודת הקצה (CPID) חייבת להחזיר שגיאת HTTP עם גוף תגובה, שחייב להכיל מופע של ErrorResponse. הודעת שגיאה טובה תכלול מידע שיעזור לנפות באגים הקשורים לשגיאה. לדוגמה, במקרה של CPID שפג תוקפו, כולל יצירת CPID וזמן תפוגה, נוכל לעזור לנו לוודא שנקודת הקצה CPID פועלת כמתוכנן.

{
    "errorMessage": "<error message>",
    "cause": "USER_ROAMING"
}

נקודת הקצה (CPID) חייבת להחזיר את המידע הבא בהתאם לתרחיש:

1. אם מתקבלת בקשת CPID עבור משתמש שאינו שייך לרשת המפעיל (למשל, משתמש השייך לאופרטור אחר אך נופל ברשת המוצג על ידי נקודת הקצה הזו של CPID), או שלא בחר לשתף מידע על תוכנית הנתונים עם Google, נקודת הקצה של CPID עשויה להחזיר קוד סטטוס 403 של HTTP עם USER_ROAMING, USER_LD_OUT או INELIGIBLE_FOR
2. אם מתקבלת בקשת CPID עם מספר טלפון לא חוקי, נקודת הקצה של CPID חייבת להחזיר HTTP 400 עם שגיאת INVALID_NUMBER.
3. אם הפורמט של נקודת הקצה (CPID) שגוי בפורמט אחר, נקודת הקצה של CPID חייבת להחזיר HTTP 400 כסיבה ל-ERROR_CAUSE_UNSPECIFIED כסיבה.
4. מסיבות אחרות של שגיאות, כל קוד שגיאת HTTP תואם הוא קביל. באופן ספציפי, HTTP 500 הוא סיבה לשגיאה שגויה בכל כשל פנימי בנקודת הקצה (CPID).