Междоменное отслеживание.

Не пропишет. Я пробовал. Он не пишет.

Гугл-аналитика не помогает, потому что нужен один идентификатор для всех доменов, а они УЖЕ разные

Пришло время поднимать Piwik, Piwik сам не поднимется.

Вот тебе работающий тест. Установщик куки: http://htz.wrk.ru/tests/xref/

Можно в параметре запроса указать куку явно: http://htz.wrk.ru/tests/xref/?id=12345

Вот тут читаем значение в другом домене. http://vault.balancer.ru/tests/xref/

Все сорцы доступны по ссылкам, кроме setter.php, вот его содержимое:

<?php

SetCookie('xref_test', @$_GET['id'], time()+3600, '/', 'vault.balancer.ru');

header('Content-type: image/png');

$image = imagecreatetruecolor(1, 1);
imagesavealpha($image, true);
imagefill($image, 0, 0, imagecolorallocatealpha($image, 0, 0, 0, 0));
imagepng($image);

Полностью развязанные машины, физически разные сервера.

Хм. У меня не работало. Даже в iframe не работало.

Хорошо, что развитие интрументов позволяет пользователям всё проще и проще блокировать такое отслеживание.

Такие вещи надо задействовать только с сознательного соглашения пользователя.

Возможно. То есть мы делаем всё ради вашего же блага, ведь если вы купили слона, а потом опять читаете статьи про слонов - значит вы хотите купить ещё одного! А мы вам лично вышлем спецпредложение.

То есть мы делаем всё ради вашего же блага

Ложь. Маркетологи всё делают для своего блага. Они заинтересованы продать ещё одного слона, потому что это принесет им больше денег. Они готовы пользователю предложить все нужные и не нужные слоны из своего ассортимента, лишь бы он их купил, но не посоветуют слонов конкурента, даже если у конкурента слоны дешевле или качественнее, или больше подходят пользователю.

Однако, это уже лучше, чем собирать без ведома юзера его данные.

То есть мы делаем всё ради вашего же блага

Ложь. Маркетологи всё делают для своего блага.

Он же не написал, что они делают всё _только_ для блага посетителя. А когда личное благо маркетолога зависит от блага потребителя, то, соответственно, маркетолог действует и ради своего блага, и ради чужого :)

Они заинтересованы продать ещё одного слона, потому что это принесет им больше денег

Разумеется. Но ведь ты смотришь слонов. Значит ты хочешь его купить! Друзьям в подарок? Жене на день рождения? У нас есть специальный розовый слон, с бантиком!

Однако, это уже лучше, чем собирать без ведома юзера его данные.

Данные мы и так собрали - ты ведь уже покупал слона. Мы просто хотим угадать заранее, что ещё ты хочешь купить :)

А у меня не работает :( В заголовке ответа кука есть. В другой вкладке открываю второй домен - куки нет. В этой же вкладке - всё равно нет.
Вызываю через $.ajax({method:'POST', url: url}).
Если url вызываю явно, из адресной строки - кука есть.
Сначала ставил сессионную, потом поставил явное время. Сначала ставил на поддомен, потом на конкретный домен. Результат одинаковый.

Ну так делай, как у меня, через однопиксельную картинку. Мой метод у тебя работает?

А картинка работает :( А в чём разница?! Чем картинка лучше?!

Видимо, разные соглашения по безопасности. Я попробовал через iframe — куки читаются из удалённого домена (хотя, понятно, с основного домена данные этого iframe недоступны), но не пишутся.

Я нагугливал (но не разбирался и не уверен, что правильно понял), что можно попробовать удалённым сервером выдавать ещё заголовок, показывающий доверенные для iframe-куков домены. Но этот механизм не во всех браузерах работает, потому и не стал разбираться.

Ещё есть вариант — POST-запросы во всплывающем окошке или редиректы. Я у себя практикую последний вариант, правда, в паре с полноценным логином. Т.е. после нажатия кнопки «отправить» и авторизации в одном домене идёт не показ пользователю страницы, а редирект в другой домен (с UUID события аутентификации), оттуда — в третий (у меня несколько доменов) и только потом — на страницу, с которой шла авторизация.

Вариант без логина/пароля тоже возможен. Если приходит «непррписанный» пользователи (отсутствует кука «записан всюду»), то мы не отдаём ему страницу, а редиректим во второй домен (с нужным идентификатором), а оттуда уже на исходную страницу и приписываем куку «всё готово», чтобы больше редиректов не было. Для пользователя ничего не изменится (вариант, когда он работает по GPRS и каждое соединение без передачи данных занимает несколько секунд не рассматриваем), лишние десятки-сотня миллисекунд ожидания при первом заходе он не заметит.

заголовок, показывающий доверенные для iframe-куков домены

Показываю.
«Access-Control-Allow-Origin» => $original_domen,
'Access-Control-Allow-Credentials'=> 'true'

Я чего только с заголовками не пробовал...

редирект в другой домен (с UUID события аутентификации), оттуда — в третий (у меня несколько доменов) и только потом — на страницу, с которой шла авторизация

Ага, понял. Три раза пробежались, везде всё что нужно выставили/отследили...

запросы во всплывающем окошке

Это совсем нехорошо.

с основного домена данные этого iframe недоступны

Это, кстати, решаемо через window.postMessage. Занятная штука.

Для пользователя ничего не изменится

Хех. У тебя, может, и не изменится. А у нас тут такие сервера, и такой код, и всё такое прекрасное, что пара секунд точно пройдёт. Если не все пять.

А у нас тут такие сервера, и такой код, и всё такое прекрасное, что пара секунд точно пройдёт. Если не все пять.

Так не обязательно же через какой-то тяжёлый CMS данные прогонять. Можно через вообще свою обёртку на голом PHP в 5 строчек :)

Ну, или, таки, вариант с однопиксельной картинкой ;)

Надо, кстати, у себя, наверное, его реализовать. Всё же, меньше редиректов при логине — надёжнее. Тем более, что планируется вообще разносить часть проектов на физически разные сервера — один упал, вся цепочка авторизации накрылась. А можно и не с однопиксельной картинкой, в прямо индикаторы вводить «авторизовано в домене N» :)

Слушай, можешь проверить две вещи? А если картинку забирать через $.ajax() - что будет? А если забирать не картинку, а, скажем, текст, но поместить его на страницу?
$.ajax({
...
}).done(function(resp)){
$('#container').text(resp.text());
}
как-то так?