GTAF używa klucza użytkownika do identyfikowania subskrybenta podczas komunikacji z Aneksem o przetwarzaniu danych. Aplikacje, które mają dostęp do pliku MSISDN użytkownika, mogą go używać jako klucza użytkownika. Z kolei aplikacje, które nie mają dostępu do MSISDN, muszą ustalić identyfikator abonamentu operatora (CPID) bez wykrywania numeru MSISDN użytkownika. W tym artykule opisujemy mechanizm, który pozwala ustalić CPI.
CPI – proces połączenia
Rysunek 2: Przebieg rozmowy pozwalający określić CPI
- Aplikacja Google w Unii Europejskiej używa wewnętrznego interfejsu Google API do pobierania adresu URL punktu końcowego CPI z GTAF. Operator jest rozpoznawany na podstawie publicznego adresu IP klienta oraz numeru MCK+MNC aktywnej karty SIM. W przypadku MVNO Google używa SPN i GID1 do określenia MVNO.
- Klient wysyła żądanie HTTP GET do punktu końcowego CPID. Operator MOŻE obsługiwać wysyłanie żądań przez HTTPS.
- Operator MAY może użyć swojej funkcji szczegółowego sprawdzania pakietów, by zidentyfikować żądanie i wstrzyknąć do niego numer telefonu użytkownika jako nagłówek HTTP.
- Punkt końcowy CPId otrzymuje żądanie, tworzy CPI i zwraca go do UE z czasem życia (TTL), który określa, jak długo UE może używać tego CPI.
W razie potrzeby operator MAY może także używać adresów IP zamiast nazw domen w adresie URL punktu końcowego CPID. Adresy IP MOGĄ być w przestrzeni prywatnej, ale muszą być osiągalne przez klientów Google wewnątrz sieci operatorów.
W ramach procesu rejestracji operator SHALL przekazuje te informacje:
- CPID_URL, z którymi aplikacje będą się kontaktować, aby uzyskać CPID. Jeden parametr CPID_URL jest wymagany, ale operator może podać kilka adresów URL, aby zwiększyć dostępność.
- Lista prefiksów adresów IP należących do operatora, a także kod urządzeń mobilnych (MNC) i kody sieci komórkowej (MNC), które ma być zmapowane na podane adresy URL CPID. Jeśli operator używa SPN lub GID1 do rozróżnienia MVNO w swojej sieci, również powinien podać te informacje. Google użyje tych informacji, aby dopasować klientów do odpowiednich punktów końcowych CPI, jak pokazano w kroku 1 na rysunku 2.
Format żądania:
GET CPID_URL
W przypadku starszych punktów końcowych punkt końcowy CPID powinien obsługiwać żądania podobne do tych:
GET CPID_URL?app={app_id}
Podczas generowania CPID punkt końcowy może ignorować parametr URL {app_id}. Musi jednak radzić sobie z żądaniem zawierającym parametr.
Żądanie do punktu końcowego CPID może zawierać nagłówek Accept-Language. Jeśli nagłówek zawiera nagłówek, wtedy zrozumiałe dla ludzi ciągi znaków w aktualizacjach wysyłane przez organ ochrony danych przy użyciu interfejsu API mobilnej transmisji danych MUSZĄ skorzystać z ustawień podanych w żądaniu CPID.
Za każdym razem, gdy klient wysyła żądanie GET CPID_URL, MUSI otrzymać nowy identyfikator CPID. Jeśli CPID zostanie utworzony, punkt końcowy CPI MUSI zwrócić odpowiedź 200 OK. Treść odpowiedzi MUSI zawierać instancję CPIDResponse.
{
"cpid": "<CPID_string>",
"ttlSeconds": 2592000
}
Zwrócone wartości CPI MUSZĄ być ważne przez ttlSeconds sekundy, nawet jeśli później subskrybent poprosił o inne CPID. Aby zapewnić komfort użytkownikom, Google zaleca używanie wartości TTL na poziomie 30 dni i nieprzekraczającej 14 dni. GTAF będzie kodować CPID według RFC2396 w kolejnych wywołaniach organu ochrony danych.
Generowanie CPI
ZALECANY sposób tworzenia punktu CPI w punkcie końcowym CPID:
CPID_string = Base64(AES(MSISDN + TimeStamp + language, secret))
Punkt końcowy CPID łączy parametr MSISDN, język wysyłany przez klienta w nagłówku Accept-Language i sygnaturę czasową o wysokiej rozdzielczości oraz szyfruje je za pomocą klucza AES za pomocą klucza secret. Sygnatura czasowa powinna odpowiadać czasowi CPI. Zaszyfrowane dane wyjściowe są zakodowane w formacie Base64. Jeśli w adresie URL używa się CPI, MUSI ono być zakodowane w adresie URL do obsługi znaków specjalnych (/+=) używanych w standardzie Base64. W szczególności, gdy obiekt GTAF wywołuje funkcję Aneksu o przetwarzaniu danych lub wywołuje interfejs API udostępniania danych na urządzenia mobilne, CPI musi być zakodowany na potrzeby adresu URL.
W zależności od sytuacji poszczególnych operatorów zastosowanie punktu końcowego CPI może nie być proste. Częstym wyzwaniem, który często napotykamy, jest uzyskanie dostępu do MSISDN w punkcie końcowym CPID. Chętnie podzielimy się zdobytą wiedzą na temat operatorów wprowadzających do Google Analytics. Skontaktuj się z nami, jeśli natrafisz na jakieś wyzwania.
Pamięć CPI
CPI wygenerowanego za pomocą opisanego wyżej mechanizmu nie trzeba przechowywać w bazie danych. Trafne informacje na temat obsługi połączeń z organem ochrony danych mogą pochodzić z CPID.
- Gdy organ ochrony danych odbierze wywołanie GTAF w celu uzyskania stanu planu lub ofert, numer MSISDN można uzyskać przez odszyfrowanie CPI i wyodrębnienie numeru MSISDN.
- Czas wygaśnięcia CPI możesz uzyskać, odszyfrowując go, a następnie wyodrębniając sygnaturę czasową wygaśnięcia.
Wymagania dotyczące dostępności i pojemności
Jeśli klient nie może pobrać CPI, nie może uzyskać dostępu do żadnych informacji z API mobilnej transmisji danych. Dlatego w celu zapewnienia dostępności punktu końcowego CPI operator SHALL musi podjąć odpowiednie kroki. Obejmuje to m.in. posiadanie wielu wystąpień punktu końcowego CPI i funkcji DPI oraz zapewnienie nadmiarowości fizycznej, witryny i sieci dla obu funkcji, a także zapewnienie odpowiednich zasobów i możliwości systemu. Dodatkowo punkt końcowy CPID oraz funkcja DPI, które wstawiają nagłówek, muszą mieć odpowiednie uprawnienia do obsługi wszystkich klientów Google żądających CPID. Punkt końcowy CPID może używać większych wartości w polu ttlSeconds, aby ograniczyć częstotliwość generowania CPID.
Przypadki błędów
Jeśli wystąpi błąd, punkt końcowy CPID MUSI zwracać błąd HTTP z treścią odpowiedzi, która MUSI zawierać instancję ErrorResponse. Dobry komunikat o błędzie będzie zawierał informacje, które mogą pomóc w debugowaniu przyczyny błędu. Na przykład w przypadku wygasłego CPI, w tym wygenerowania go i wygaśnięcia, pomoże nam to potwierdzić, że punkt końcowy CPI działa zgodnie z oczekiwaniami.
{
"errorMessage": "<error message>",
"cause": "USER_ROAMING"
}
W zależności od okoliczności punkt końcowy CPI musi zwracać:
- Jeśli otrzyma się żądanie CPI w przypadku użytkownika, który nie należy do sieci operatora (np. użytkownika należącego do innego operatora, ale korzystającego z roamingu w sieci zarządzanej przez ten punkt końcowy CPI) lub nie zgodził się na udostępnianie Google informacji o planie danych CPI, musi on zwracać kod stanu HTTP 403 użytkownikowi USER_ROAMING, USER_OPT_OUT lub INELIGIBLE_FOR_SERVICE.
- Po otrzymaniu żądania CPI z nieprawidłowym numerem telefonu punkt końcowy CPI MUSI zwracać błąd HTTP 400 z powodu błędu INVALID_NUMBER.
- Jeśli żądanie skierowane do punktu końcowego CPID jest zniekształcone w inny sposób, punkt końcowy CPID MUSI zwrócić HTTP 400 z przyczyną ERROR_CAUSE_UNSPECIFIED.
- W przypadku innych problemów dopuszczalny jest dowolny zgodny kod błędu HTTP. Konkretnym powodem błędu w przypadku każdej wewnętrznej awarii punktu końcowego CPI jest HTTP 500.