GTAF использует ключ пользователя для идентификации подписчика при общении с DPA. Приложения, имеющие доступ к MSISDN пользователя, могут использовать его как user_key. С другой стороны, приложения, не имеющие доступа к MSISDN, должны установить идентификатор тарифного плана (CPID), не обнаруживая MSISDN пользователя. Далее мы опишем механизм, который устанавливает CPID.
Поток вызовов CPID
Рисунок 2: Поток вызовов для установления CPID.
- Приложение Google в UE использует внутренний API Google для получения URL-адреса конечной точки CPID из GTAF. Оператор идентифицируется с помощью общедоступного IP-адреса клиента и MCC+MNC активной SIM-карты. В случае MVNO Google будет использовать SPN и GID1 для определения MVNO.
- Клиент отправляет запрос HTTP GET к конечной точке CPID. Оператор МОЖЕТ поддерживать отправку запроса через HTTPS.
- Оператор МОЖЕТ использовать свою функцию Deep Packet Inspection для идентификации запроса и добавления номера телефона пользователя в запрос в качестве заголовка HTTP.
- Конечная точка CPID получает запрос, формирует CPID и возвращает CPID в UE со временем жизни (TTL), указывающим, как долго UE может использовать этот CPID.
Оператор МОЖЕТ также использовать IP-адреса вместо доменных имен в URL-адресе конечной точки CPID, если это предпочтительно. IP-адреса МОГУТ находиться в частном адресном пространстве, но они должны быть доступны клиентам Google в сети оператора.
Оператор ДОЛЖЕН предоставить Google следующую информацию в рамках процесса регистрации:
- CPID_URL, к которому приложения будут обращаться для получения CPID. Один CPID_URL является обязательным, но оператор может указать несколько URL-адресов для повышения доступности.
- Список IP-префиксов, которыми владеет оператор, а также мобильный код страны (MCC) и код(ы) мобильной сети (MNC), которые оператор хочет сопоставить с предоставленными CPID_URL. Если оператор использует SPN или GID1 для различения MVNO в своей сети, оператор ДОЛЖЕН также предоставить эту информацию. Google будет использовать эту информацию для сопоставления клиентов с соответствующими конечными точками CPID, как показано на шаге 1 на рис. 2.
Формат запроса: GET CPID_URL
По устаревшим причинам конечная точка CPID должна иметь возможность поддерживать следующий запрос:
GET CPID_URL?app={app_id}
Конечная точка CPID может игнорировать параметр URL-адреса {app_id}
при создании CPID. Но он ДОЛЖЕН иметь возможность обрабатывать запрос, содержащий параметр.
Запрос к конечной точке CPID МОЖЕТ включать заголовок Accept-Language
. Если заголовок включен, то удобочитаемые строки в обновлениях, которые DPA отправляет с использованием API совместного использования планов мобильных данных, ДОЛЖНЫ использовать настройки, указанные в запросе CPID.
Каждый раз, когда клиент отправляет запрос GET CPID_URL, он ДОЛЖЕН получить новый CPID. Если создание CPID прошло успешно, конечная точка CPID ДОЛЖНА вернуть ответ 200 OK. Тело ответа ДОЛЖНО содержать экземпляр CPIDResponse .
{
"cpid": "<CPID_string>",
"ttlSeconds": 2592000
}
Возвращенный CPID ДОЛЖЕН быть действительным в течение ttlSeconds секунд, даже если подписчик впоследствии запросил другие CPID. Google рекомендует использовать значение TTL 30 дней, но не менее 14 дней для лучшего взаимодействия с пользователем. GTAF будет кодировать CPID в соответствии с RFC2396 при последующих обращениях к DPA.
Генерация CPID
РЕКОМЕНДУЕМЫЙ способ для конечной точки CPID создать CPID:
CPID_string = Base64(AES(MSISDN + TimeStamp + language, secret))
Конечная точка CPID объединяет MSISDN, язык, отправленный клиентом в заголовке Accept-Language, и отметку времени с высоким разрешением и шифрует ее через AES с использованием secret
ключа. Временная метка ДОЛЖНА соответствовать времени истечения срока действия CPID. Зашифрованный вывод имеет кодировку Base64. Кроме того, когда CPID используется в URL-адресе, он ДОЛЖЕН быть закодирован в URL-адресе для обработки специальных символов (/+=), используемых в Base64. В частности, когда GTAF вызывает DPA или когда DPA вызывает API совместного использования планов мобильных данных, CPID ДОЛЖЕН быть закодирован в URL-адресе.
В зависимости от ситуации конкретного оператора реализация конечной точки CPID может быть нетривиальной. Особой проблемой, с которой часто приходится сталкиваться, является получение доступа к MSISDN в конечной точке CPID. Мы рады поделиться уроками, извлеченными операторами на борту. Пожалуйста, свяжитесь с нами, если вы столкнетесь с какими-либо трудностями.
Хранилище CPID
CPID, сгенерированный с использованием описанного выше механизма, не обязательно хранить в базе данных. Соответствующая информация для обработки обращений к DPA может быть получена из CPID.
- Когда DPA получает запрос от GTAF о статусе плана или предложениях, MSISDN может быть получен путем расшифровки CPID и извлечения MSISDN.
- Время истечения срока действия CPID может быть получено путем расшифровки CPID и последующего извлечения метки времени истечения срока действия.
Требования к доступности и мощности
Если клиенты не могут получить CPID, они не могут получить доступ к какой-либо информации из API плана мобильных данных. По этой причине оператор ДОЛЖЕН принять необходимые меры для обеспечения доступности конечной точки CPID. Такие меры включают в себя наличие нескольких экземпляров конечной точки CPID и функций DPI, а также физическую, локальную и сетевую избыточность для обеих функций, а также обеспечение адекватности системных ресурсов и пропускной способности. Кроме того, конечная точка CPID, а также функция DPI, которая внедряет заголовок, должны иметь достаточную мощность для обработки нагрузки всех клиентов Google, запрашивающих CPID. Конечная точка CPID может использовать большие значения в поле ttlSeconds
, чтобы уменьшить частоту генерации CPID.
Случаи ошибок
Если происходит ошибка, конечная точка CPID ДОЛЖНА вернуть ошибку HTTP с телом ответа, которое ДОЛЖНО содержать экземпляр ErrorResponse . Хорошее сообщение об ошибке должно содержать информацию, которая может помочь в отладке причины ошибки. Например, в случае просроченного CPID, в том числе время создания и истечения срока действия CPID, мы можем убедиться, что конечная точка CPID работает должным образом.
{
"errorMessage": "<error message>",
"cause": "USER_ROAMING"
}
Конечная точка CPID ДОЛЖНА возвращать следующее в зависимости от сценария:
- Если запрос CPID получен для пользователя, который не принадлежит к сети оператора (например, пользователь, принадлежащий другому оператору, но находящийся в роуминге в сети, обслуживаемой этой конечной точкой CPID) или который не решил делиться информацией о тарифном плане с Google, Конечная точка CPID ДОЛЖНА возвращать код состояния HTTP 403 с USER_ROAMING, USER_OPT_OUT или INELIGIBLE_FOR_SERVICE в качестве причины.
- Если получен запрос CPID с недопустимым номером телефона, конечная точка CPID ДОЛЖНА вернуть HTTP 400 с причиной ошибки INVALID_NUMBER.
- Если запрос к конечной точке CPID искажен каким-либо другим образом, конечная точка CPID ДОЛЖНА вернуть HTTP 400 с ERROR_CAUSE_UNSPECIFIED в качестве причины.
- Для других причин ошибки допустим любой совместимый код ошибки HTTP. В частности, HTTP 500 является подходящей причиной ошибки для любого внутреннего сбоя в конечной точке CPID.