Есть ли способ обхода сторонних файлов cookie в Iframe для сафари?

У меня есть требование перейти на сторонний сайт (SSO) из моего приложения, это хорошо работает в Chrome, IE9 и Firefox, но не в сафари. Было обходное решение для скрытия iframe на странице, чтобы установить файл cookie, а затем перейти к фактическому iframe, но этот трюк больше не работает. Я также попытался открыть новое окно с действием в качестве стороннего URL-адреса, чтобы установить cookie в браузере, а затем открыть его в iframe, но это имеет недостаток в том, что это маленькое окно, которое открывается, похожее на какой-то хак. Есть ли способ обхода файла cookie в iframe для браузера сафари?

4b9b3361

Введение в файлы отслеживания

"Отслеживание файлов cookie" - очень важная часть экосистемы интернет-рекламы. Это тонны сценариев использования. Здесь один пример называется перенацеливанием.

Известно, что многие интернет-покупатели не покупают сразу после того, как они увидели хорошую сделку на веб-сайте электронной коммерции. Сначала они выбирают хороший, оставляют сайт и возвращаются через пару часов или дней, чтобы сделать фактический заказ.

Чтобы стимулировать пользователей, веб-сайты используют так называемую технологию перенацеливания. В основном, они хотят помнить пользователей, которые покинули свой веб-сайт, не делая заказ, и показывают им соответствующую рекламу на других сайтах. Обычно веб-сайты электронной коммерции делегируют такую ​​работу рекламным платформам онлайн, таким как AdExchanges, DSP и т.д.

С технической точки зрения он работает следующим образом:

  • Владелец сайта помещает небольшой фрагмент кода HTML. Кусок кода называется "пикселем отслеживания". Рассмотрим простой случай, когда пиксель отслеживания является прозрачным GIF-изображением:

    ... <img src="http://pixel.sample-ad-exchange.com/pixel.gif">..

  • http://pixel.sample-ad-exchange.com/pixel.gif отбрасывает файл cookie для домена .sample-ad-exchange.com 'с именем user_id. В этом cookie сохраняется уникальный идентификатор пользователя (если файл cookie уже существует, сервер просто пропускает эту часть)

  • sample-ad-exchange.com запоминает внутренне этот пользователь с этим посещенным сайтом электронной коммерции

  • Когда sample-ad-exchange.com предлагается показывать объявление где-то в другом месте (например, вызывая tag.sample-ad-exchange.com/show_ad.js), он получает cookie user_id вместе с http request

  • sample-ad-exchange.com проверяет внутренне, если этот пользователь ранее посещал сайты электронной коммерции. Если он есть, он может показать ему очень релевантное объявление

Проблема

Как вы можете видеть, способность отказаться от cookie - это жизнеспособная часть схемы перенацеливания. Такие куки называются "сторонними куки", потому что пиксельный код находится в домене рекламодателя (например, my-cool-store.com), а сам пиксель находится на стороннем домене для обмена объявлениями (.sample-ad-exchange.com). По умолчанию разные браузеры имеют разную политику в отношении сторонних файлов cookie.

Chrome, Firefox, IE до 8.0 - всегда принимать сторонние файлы cookie

IE 8.0 и выше - принимать сторонний файл cookie только в том случае, если на веб-сайте явно указано, как он будет использовать файлы cookie. Декларация выполняется через протокол P3P. Как и каждая спецификация от W3C, этот тоже очень загадочный. Но сутью является заголовок HTTP под названием "P3P", который вам нужно отправить вместе с ответом HTTP, содержащим cookie. Это содержимое заголовка прекрасно работает, хотя я понятия не имею, что именно он объявляет: "P3P: CP =" NOI DSP COR NID CURA ADMa DEVa PSAa PSDa НАША АВТОМАТИЧЕСКАЯ КОММУТА INT OTC PUR STA "

Safari - никогда не принимает сторонние файлы cookie

Safari не была большой проблемой для индустрии, прежде чем появился iPad и приобрел огромную популярность. Исследования показывают, что пользователи iPad, как правило, делают покупки в Интернете даже больше, чем обычные ребята ПК.

Trick 1.0 (больше не работает)

Фактически Safari иногда не отказывается от файлов cookie 3rdparty. Это происходит, если пользователь сделал некоторые действия, связанные с доменом 3rdparty. Google Analytics (и другие платформы тоже) воспользовались этой функцией: они вставили внутри нее iframe и смоделировали форму sumbit. Здесь я не остановлюсь на технических подробностях. Во-первых, этот взлом стоит $22,5 млн., А во-вторых, трюк больше не работает в последних версиях Safari

Trick 2.0 (HTML5 localStorage)

Идея этого трюка заключается в использовании API-интерфейса HTML5 localStorage. Этот API очень похож на файлы cookie - он позволяет управлять предпочтениями пользователей с javascript и хранить их локально в ящике пользователя. Почему бы не сохранить идентификатор пользователя в localStorage? В первой версии кода я придумал:

  <script type="text/javascript">
if (typeof navigator != "undefined" && typeof navigator.vendor != "undefined" &&                               navigator.vendor.indexOf("Apple") >= 0 && typeof localStorage != "undefined") {
    //Check if browser is made by Apple (means it Safari) and local storage is available
    var userId = localStorage.getItem("user_id");
    if (userId == null) {
        //set user is if user is unknown
        userId = Math.random();
        localStorage.setItem("user_id", userId);
    }
    var img = document.createElement('img');
    img.src = "http://pixel.sample-ad-exchange.com/pixel.gif?user_id=" + user_id;
    var body = document.getElementsByTagName('body')[0];
    body.appendChild(img);
}

Идея довольно проста: найдите ключ user_id в локальном хранилище (создайте его, если он не существует) и передайте user_id на пиксельный сервер как параметр GET. Тогда сервер будет записывать этот идентификатор, а не стрелять из файла cookie.

Но этот код не работает. У каждого домена есть собственное локальное хранилище. И если отслеживание пикселя было запущено на my-cool-store.com, user_id будет храниться в локальном хранилище my-cool-store.com. Если тот же пользователь посетит other-domain.com с кодом отслеживания позже, он будет рассматриваться как новый.

Чтобы исправить этот старый хороший трюк с iframe, он будет работать. Вместо img-тега мы будем вставлять тег iframe с источником где-то внутри pixel.sample-ad-exchange.com. И поместите код обнаружения пользователя внутри iframe. Поскольку iframe выполняется "внутри" pixel.sample-ad-exchange.com, локальное хранилище будет одинаковым для всех отслеживаемых сайтов. Вот полный пример:

Код отслеживания:

<script type="text/javascript">
if (typeof navigator != "undefined" && typeof navigator.vendor != "undefined" &&       `navigator.vendor.indexOf("Apple") >= 0 && typeof localStorage != "undefined") {`
    var iframe = document.createElement('iframe');
    img.src = "http://pixel.sample-ad-exchange.com/iframe.html";
    var body = document.getElementsByTagName('body')[0];
    body.appendChild(img);
}
</script>

Код iframe (http://pixel.sample-ad-exchange.com/iframe.html)

<html>
<head></head>
  <body>
  <script type="text/javascript">
var userId = localStorage.getItem("user_id");
if (userId == null) {
    //set user is if user is unknown
    userId = Math.random();
    localStorage.setItem("user_id", userId);
}
var img = document.createElement('img');
img.src = "http://pixel.sample-ad-exchange.com/pixel.gif?user_id=" + user_id;
var body = document.getElementsByTagName('body')[0];
body.appendChild(img);
</script>
</body>
</html>

Правовая проблема

Интересный вопрос в том, является ли этот метод законным. Znd, если следующая компания, использующая его, получит штраф в размере 22,5 миллиона долларов. Я не юрист, но с точки зрения здравого смысла, поскольку настройки Safari явно говорят: "Блокируйте файлы cookie сторонних сторон от третьих лиц и рекламодателей", а localStorage - это не "cookie", описанный выше подход кажется законным.

10
21 авг. '14 в 11:47
источник

Скрытые (или не скрытые!) iframe не будут работать, поскольку они все равно будут нарушать политику одного и того же происхождения.

Попробуйте найти CORS - "Перекрестный ресурс ресурсов". Это стандарт, который теперь реализован во всех основных браузерах.

2
18 авг. '14 в 16:26
источник