iOS: Вход в Omniture через прокси-службу

Question

Я разрабатываю приложение iOS для клиента с жесткими требованиями безопасности. Мне нужно регистрировать аналитику с помощью Omniture. Приложение работает с чрезвычайно конфиденциальными данными, а для обеспечения безопасности я не могу совершать вызовы из приложения напрямую в URL-адрес Omniture sitecatalyst. Вместо этого мне нужно настроить службу на внутреннем веб-сервере приложений, который затем сделает вызов Omniture (таким образом, вызов будет маршрутизироваться через безопасный шлюз, как и другие веб-службы, вызываемые из приложения iOS)

Я вижу два варианта для этого.

1. Я создал структуру Omniture в моем приложении и сделать звонки (за исключением настроить вызовы, чтобы перейти к https://myserverurl.com/analyticsservice вместо https://sc.omniture.com) я затем настроить сервлет или JSP в https://myserverurl.com/analyticsservice для обработки запроса. Затем сервлет (написанный с помощью SDK Omniture) передаст вызов https://sc.omniture.com.

2. Я не устанавливаю рамки Omniture в своем приложении. Вместо этого я установил простой веб-сервис аналитики на своем сервере. Webservice (написанный с помощью Onniture SDK) будет принимать параметры, которые я передаю из приложения iOS, и сделать обратный вызов https://sc.omniture.com.

См. Рисунки 1 и 2, иллюстрирующие каждый вариант. Вариант 2 кажется более чистым, в то время как Вариант 1 может немного поиграть - с фальсификацией Джерри, чтобы заставить Omniture работать. Имея жесткую временную шкалу, я был бы признателен за любые мнения и советы относительно того, какой вариант взять (плюсы, минусы, другие соображения и т. Д.), Прежде чем я погружусь в Доказательство концепции.

Спасибо!

Answer 1

После запуска ДОУ на обоих подходах - я нашел подход 2 будет правильный подход. Подход 1 на самом деле не работает - причина в том, что API-интерфейс клиента Omniture - это первое, что активируется при запуске приложения и локальной базе данных Omniture в приложении. Приложение (закодированное с настраиваемой безопасностью api) после аутентификации пользователя удаляет контейнер приложения по умолчанию и заменяет его собственным контейнером. Поэтому в следующий раз Omniture пытается записать все, что он пытается записать в указатель базы данных, на котором он держался (когда он создал локальную базу данных), не зная, что приложение заменило эту базу данных, когда она воссоздала контейнер приложения. Это приводит к сбою приложения.

Таким образом, ответ оказывается подход 2.

Answer 2

URL Omniture также протокол HTTPS, я думаю. Я не уверен, что вы получаете дополнительную защиту, выполняя все это (отправляя на свой сервер и отправляя обратно на omniture). С другой стороны, для обработки всех этих данных вам необходимо иметь бэкенд высокой емкости.

Опять же, если кто-то может украсть данные из https, он может сделать это даже из вашего соединения от бэкэнда до omniture.

Я бы предложил вместо этого удалить все личные и конфиденциальные данные перед отправкой событий в Omniture. И отправьте его прямо из приложения iOS на сервер omniture. Это очень дружественной к вашей сжатые сроки, а также :-)

(Или же я понимаю вещи совершенно неправильно?)