Pull to refresh

Comments 71

Разные веб-сервера шлют дату в разных форматах, иногда не в стандартных. Соответственно браузерам нужно под их формати подстраиватся, а это не только геморно но и не всегда возможно (т.к. для одной строки могут подходить больше одного стандарта). Думаю проблемку нужно на уровне спецификация протокола решать…
Спека, правда, уже говорит об этом:
The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified.
       Last-Modified  = "Last-Modified" ":" HTTP-date



А HTTP-date обозначен тут: www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1

То есть, в теории, все уже заспецифицировано и запротоколировано по самое не хочу. Но как всегда, все на спецификации глубоко наплевать :)
HTTP-date допускает три разных формата, плюс время указывается с точностью до секунды, итого в одних сутках содержится 259 200 различных уникальных идентификаторов. Учитывая, что на реальное значение Last-modified нам плевать, и мы можем хоть прошлый год там выставить — ситуация не намного лучше, чем с произвольной строкой.
Это тоже верно. Как автор и указал, это — только частичное решение, а полного, увы, нет
Ну, можно в некоторых разумных пределах fuzzing поля делать.
15 секунд туда-сюда при каждом запросе. Чем более старая дата — тем больше допустимая амплитуда отклонения.

Процент ложных запросов мимо кеша вырасти особо не должен в подавляющем большинстве случаев, а у идентификации возникнут очевидные проблемы.
Проблему это не решит. Кто мешает выделять на одного пользователя для отслеживание хоть амплитуду в одну — две недели?
Браузер должен парсить дату чтобы определить формат используемый сервером, а потом в If-modified-since выставлять её по системным часам клиента, а не тому что отдал сервер. :]
И чем это усложняет идентификацию?
Действительно, чем усложнит идентификацию тот факт, что мы выдаём клиенту один идентификатор, а он возвращается с другим?
Если мы указываем часовой пояс, то ничего не изменилось — конвертнули в нужное время, получили тот же токен.

Если мы не указываем часовой пояс, то рушим работу с нормальными серверами.
Я так понял, нужно в If-Modified-Since подставлять значение часов клиента на момент получения предыдущей страницы. В этом случае совершенно всё равно, что там прислал сервер в прошлый раз.
Тогда у нас сразу же возникают проблемы с кэшированием и показыванием правильной версии клиенту.
У меня два предположения, что вы подразумеваете под фразой «выставлять её по системным часам клиента»: либо менять часовой пояс, либо посылать текущее время. Второй случай не несет в себе смысла.
Цитата> Метод, основанный на ETag'ах работает не всегда, особенно если на пути стоят web-проки, а вот метод, основанный на Last-Modified срабатывает всегда. <Цитата

Нет, тоже не всегда. Только что проверил — мой прокси в запросе If-Modified-Since указывает тот момент времени, когда он поместил этот объект в кэш, а не ту строку, которую сервер выдавал в тот момент.
Переводил в спешке, поэтому могут быть неточности и кривости в изложении :) Главное, ногами не бейте :)
Тут главное суть проблемы, а она отлично понятна.
В Опере пример не работает, Last-Modified не ставится.
Как-то сомнительно использование этого трюка для идентификации, ведь браузер пошлет If-Modified-Since только на тот же самый url, на другие он слать не будет.
В Эксплорере тоже. «Срабатывает во всех основных браузерах» вызывает сомнение.
Трюк нужен для сайтов, ставящих отслеживающие куки. То есть достаточно поставить img href=«tracker-site/url/», чтобы получать информацию о том, куда и как ходит пользователь
А как вы получите информацию, куда он ходит? По рефереру?
Можно по рефереру. Можно по дополнительному токену в url'е.
В том то и дело — изменяем url, браузер больше не шлет If-Modified-Since.
И кто же будет менять этот url?
Вы, раз собираетесь в url добавлять токен с информацией о текущей странице.
Блин. Я захожу на страницу site.url, на нем есть <img url="site2.url">. site2.url и есть сайт, который отслеживает ваши перемещения. Что и как вы собираетесь менять?
Как он отслеживает перемещения? Каким образом, кроме реферера, он может узнать, на какой странице стоит тег <img url="site2.url">? Вы упомянули про тукен в url, где он здесь?
Что ему мешает узанть из referer'а?
Что мешает автору сайта site1.url добавить токен в урл?

Какой это отношение имеет к вопросу «И кто же будет менять этот url?»?
> Что ему мешает узанть из referer'а?
Ничего не мешает узнать по рефереру, просто вы упомянули второй способ, который я у вас выпытываю.

> Что мешает автору сайта site1.url добавить токен в урл?
В какой url? В site2.url?
Да. В site2.url.

Начнем с начала.

Вы — пользователь. Вы открыли бразуер по адресу site.url, на нем есть <img url="site2.url">. site2.url и есть сайт, который отслеживает ваши перемещения

Без разницы, что находится в site2.url.

Вы задаете вопрос:
В том то и дело — изменяем url, браузер больше не шлет If-Modified-Since.


Кто будет менять этот самый site2.url?
Дальше, пожалуйста. «Xтобы получать информацию о том, куда и как ходит пользователь». Я захожу на site.url/info/, что там?
Блин. Такое ощущение, что я разговариваю со стенкой.

Заходите туда, там есть страница, на которой в самом низу есть картинка размером 1x1, которая берется с сайта site2.url. Хоть с токеном, хоть без токена — без разницы.

Дальше. Куда применять ваше
В том то и дело — изменяем url, браузер больше не шлет If-Modified-Since.

?
Ага, в данном случае стенка — вы.

Если адрес картинки на сайте site2.url будет точно такой-же как на странице site.url/, то сайт site2.url получит возможность идентифицировать пользователя, но он никак не узнает, на какую страницу попал пользователь. Все что он сможет сказать — сколько раз каждый пользователь дернул url.

Если же мы передаем в url для site2.url какой-то тукен с зашифрованных url первого сайта, то site2 сможет сказать, какие урлы открывались на первом сайте. Но вот беда, он не сможет определить, один и тот-же это был пользователь, или нет, потому что урлы-то разные.
> но он никак не узнает, на какую страницу попал пользователь

referer'ы у нас уже отменили?

> Но вот беда, он не сможет определить, один и тот-же это был пользователь, или нет, потому что урлы-то разные.

это тож решаемо. Более того, полезно для сбора статистики
ах. и да. url/ и url/?token=xxxx — это один и тот же URL
OMG!
dmitriid> Трюк нужен… чтобы получать информацию о том, куда… ходит пользователь

homm> А как вы получите информацию, куда он ходит?

dmitriid> по дополнительному токену в url'е

homm> В том то и дело изменяем url, браузер больше не шлет If-Modified-Sinceа это, по мнению homm`а противоречит Вашему первому утверждению! После чего, как я понимаю, Вы полностью запутались выясняя что и как
Бл*ть.

КТО будет изменять URL?

Вы — пользователь. Вы открыли бразуер по адресу site.url, на нем есть . site2.url и есть сайт, который отслеживает ваши перемещения

Без разницы, что находится в site2.url.

Кто будет менять этот самый site2.url?
> site2.url и есть сайт, который
> отслеживает ваши перемещения
Как он их отслеживает без реферера? Как он для этого использует упомянутый вами токен?
3.3. Path — это не то, что вы выделили, а только «/url», до этого идут домен и схема.
Вы уже бред несете.
> referer'ы у нас уже отменили?
Но вы же хотели рассказать способ без реферерров!!!111
> это тож решаемо.
Но решаемо не с помощью уязвимости, о которой вы сделали перевод. Да?
На site1.com/page1 стоит картинка 'site2.com/tracker.png?urlhash=' +md5('site1.com/page1'). Так мы будем знать и куда конкретно заходил, а не только факт захода.
Ну и каким макаром в запрос на адрес
'site2.com/?'+md5('/page1') попадет заголовок If-Modified-Since из заголовка ответа Last-Modifed от запроса на 'site2.com/?'+md5('/page2'), если это разные урлы?
В первый раз сервер установит «этот клиент первый раз посетил эту страницу», а во второй уже можно будет отслеживать сколько раз он её посещал, а если будет уходить и на другие уже посещенные страницы, то и маршруты отслеживать. Не столь универсально как куки, токены и реферы, но лучше чем ничего, если клиент параноидальный и всё это отключил, а про кэш забыл.
а если будет уходить и на другие уже посещенные страницы, то и маршруты отслеживать
Как? Нет — КАК??!!! У вас не будет данных, что человек, зашедший по md5('/page1') и md5('/page2') — один и тот же, или это разные люди. Браузер не пошлет заголовки одного адреса по другому.

Я допускаю, что я чего-то очевидного в упор не замечаю, но что-то пока никто на это очевидное указать не может.
Да, тут я что-то ступил. Параметры в URL являются тоже частью «идентификатора» ресурса (в отличии от якоря). Отслеживать получится только как часто какой-то пользователь возвращается на конкретную страницу, но он ли посещает соседнюю страницу сказать нельзя будет без анализа других заголовков и служебной инфы типа айпишника.
это — не разные URL'ы. Читайте спеки, они рулят.
Парсер съел собки, поэтому приведу-ка я:
An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>


После чего надо все же читать про URI тут: tools.ietf.org/html/rfc3986 особенно секцию 3.3 path:
The path component contains data, usually organized in hierarchical
form, that, along with data in the non-hierarchical query component
(Section 3.4), serves to identify a resource within the scope of the
URI's scheme and naming authority (if any). The path is terminated
by the first question mark ("?") or number sign ("#") character, or
by the end of the URI.


Ну path, и че? А дальше идут 3.4. Query и 3.5. Fragment — следующие части url.
Осталось узнать, is-modified-since отправляется по URI path или по всему URL'у
Не пой части, что шлется на сервер, т.е. по url без Fragment, мистер «блядь, я читаю доки, разговариваю как со стенкой».
Ваш поток сознания мне непонятен
Если браузер очищает кеш после закрытия, то и заголовки эти отправлять нет смысла.
Ну да, это — единственное решение.
Заголовок «Cache-Control: no-cache» заставляет фаерфокс и хром не отсылать If-Modified-Since и If-None-Match. В других браузерах не проверял.
вот все почему-то думают, что это плохо, один я не понимаю, почему, и как разработчик веб-приложений мне очень надо возможность отслеживать посетителей. в том числе и для того, чтобы этим же посетителям сделать жизнь на сайте лучше и комфортнее.
Благими намерениями выстлана дорога в… индекс Яндекса и Гугла :)
капитан подсказывает, что решение, отслеживать себя или нет, должен принимать все-таки пользователь

вам же в реале не понравилось бы, если бы за вами по пятам ходил дядька и записывал все, что вы делаете, пусть даже вам от этого была какая-то польза?
Известный гик Chris Siebenmann ответил на это в своём блоге:
I feel that changing Last-Modified is basically impossible for the browser to do in a way that is both safe and useful.
UFO just landed and posted this here
Кстати… а сами сервера парсят даты? Или просто формируют новую строку для Last-Modified и сравнивают её на равенство с переданной клиентом?
Sign up to leave a comment.

Articles

Change theme settings