Xpoint
   [напомнить пароль]

Как уберечь cookies от затирания при переполнении лимита 20?

Метки: [без меток]
2006-01-24 09:53:56 [обр] Даниэль Алиевский(9/125)[досье]

В моем сервисе webwarper один пользователь может просматривать множество сайтов. При этом просматриваемые сайты, с точки зрения броузера, относятся к домену webwarper.net (скажем, webwarper.net/ww/~av/google.com/). Некоторые из сайтов устанавливают куки, которые превращаются в куки домена webwarper.net. Поэтому, естественно, лимит 20 cookies / domain быстро исчерпывается.

Это, конечно, неприятно, но, насколько я понимаю, непреодолимо. Пользователь вынужден смириться, что при работе через WW сайты могут довольно быстро "забывать" про него. В конце концов, WW предназначен главным образом для простого просмотра большого количества разнородных сайтов, а не для активной интерактивной работы в определенном форуме (которая обычно порождает куда меньше трафика).

Гораздо хуже, что cookies нужны мне самому, для управления режимами работы WW. Например, если пользователь купил регистрационный код и отключил рекламу на год, эта информация запоминается в cookie все того же домена webwarper.net. И если этот cookie исчезнет из-за переполнения лимита 20 cookies, будет неприятно - реклама появится, и пользователь будет вынужден вводить регистрационный код повторно.

Поэтому вопрос - как можно надежно уберечь cookies от затирания?

  1. Во всевозможной документации про cookies говорится, что при переполнении удаляется самый старый cookie. Значит ли это, что если я буду непрерывно обновлять свои cookies (допустим, выполнять document.cookie=... для всех имеющихся cookies при каждой загрузке очередной страницы), то с очень высокой вероятностью они не будут затерты? Если не трудно, подскажите - что об этом говорят стандарты и ваш богатый опыт работы с разными броузерами :)
  1. Как мне кажется, есть 100% надежный способ - хранить мои cookies в другом домене (допустим, algart.org). Но способ сей основан на IFRAME и этим мне не нравится. Не всегда удобно читать или устанавливать cookie только по окончании загрузки страницы, когда все IFRAME заведомо загрузились. Идея метода проста: я всегда могу загрузить в IFRAME скрипт из другого домена (простым window.open с указанием имени IFRAME), передав в качестве параметра значение cookie или запрос на чтение cookie. В ответ на запрос на чтение скрипт внутри IFRAME (из другого домена) может, прочитав cookies из своего document.cookie, загрузить в другой IFRAME скрипт из исходного домена, передав ему cookies в параметрах. А тот уже будет обладать правами, чтобы сообщить значение в исходную страницу.

Однако, повторю - этот метод неудобен. Кроме того, он приводит к лишнему бессмысленному трафику. Кроме того, надо решать проблемы передачи параметров (длина строки GET-запроса ограничена где-то 1000 байтами, причем с учетом кодировки URL-encoding, в то время как даже один cookie может достигать 4 KB). И вообще все это сложно и криво.

Так что прошу подсказать: может быть, достаточно регулярного обновления cookies - метод №1? Или, может быть, есть другие известные приемы преодоления ограничения 20 cookies/domain?

спустя 2 часа 34 минуты [обр] Digital man 53(0/3)[досье]
Можно присваивать каждому юзеру уникальный идентификатор, который будет храниться в куках. При обращении к странице чужого сервера перехватывать Set-cookie и записывать нужную информацию в базу. При следующем обращении к этому сайту отдавать заголовок Cookie с записанными значениями. Тогда проблемы 20 cookies/domain не будет в принципе.
ЗЫ: чистая теория, на практике не проверено
спустя 16 минут [обр] Сергей Круглов(33/2057)[досье]

присваивать идентификатор и делать его доменом 3-его уровня.

5324531782123.webwarper.com/blablabla

спустя 49 минут [обр] Даниэль Алиевский(9/125)[досье]

Digital man 53[досье] Спасибо. Но чересчур сложно. Мне ведь придется воспроизвести на сервере всю логику броузера работы с куками - привязку их к путям, поддоменам, следовать всем ограничениями вроде 20 cookies/домен. Я никогда не писал броузеры, проверенных алгоритмов для этого у меня нет :) Кроме того, прикиньте размеры такой базы. Если каждый посетитель будет хранить в среднем 10 KB кукисов (по всем сайтам, по которым он ходит), а в год у меня порядка миллиона посетителей - это уже +10 GB каждый год. По каким правилам ее чистить, неочевидно. А если популярность подрастет? А если посетители будут хранить не 10, а 100 KB? (Как я понимаю, стандарт предусматривает ограничение 300*4=1200 KB.)

Сергей Круглов[досье] Я думал об этом. Может быть, я просто неправильно думаю - недостаточно разобрался. Откуда DNS провайдера пользователя узнает, что из себя представляет адрес вроде google.com.webwarper.net? Разве броузер обратится к серверу webwarper.net, передав ему некую дополнительную информацию? Разве можно таким образом настроить Apache, чтобы некий единый скрипт перехватывал все обращения типа произвольнаястрока.webwarper.net и возвращал адекватный результат?

спустя 19 минут [обр] Сергей Круглов(33/2057)[досье]

Да, это возможно. Я точно не знаю как настраивается, но видел я как-то хостинг, где создаешь директорию и в ту же секунду имеешь соответствующий поддомен.

Попингайте чтоугодно.nic.ru, например.

спустя 2 минуты [обр] Сергей Круглов(33/2057)[досье]
Ой, не nic, а что угодно.inc.ru
спустя 3 минуты [обр] Алексей Севрюков(0/1280)[досье]
Даниэль Алиевский[досье] Для этого достаточно прописать дополнительную MX запись и обрабатывать такой домен как несуществующий, выцепляя скриптом хост к которому было обращение. AFAIK.
спустя 13 минут [обр] Андрей Пахомов(0/310)[досье]
Алексей Севрюков[досье]
а причем здесь MX ? Я так понимаю речь все таки не о почте. Вроде надо написать просто что то вроде этого:
* IN A webwarper.com
спустя 6 минут [обр] Алексей Севрюков(0/1280)[досье]
Андрей Пахомов[досье] Не совсем разбираюсь в теме. Да, именно A.
спустя 13 минут [обр] Даниэль Алиевский(9/125)[досье]

Сергей Круглов[досье]

Да, это возможно. Я точно не знаю как настраивается, но видел я как-то хостинг, где создаешь директорию и в ту же секунду имеешь соответствующий поддомен.

Так это другая ситуация. Конечно, если у хостинга ОДИН пользователь (заказчик), и он хочет создать поддомен, то почему бы сразу не внести в DNS провайдера нужную запись и не перенастроить httpf.conf.

У меня иная картина. 10 раз в секунду разные случайные люди заходят на самые разные сайты. Возможно, каждую секунду несколько из них - новые, то есть ранее неизвестные мне домены (Internet велик). Более того, единственный признак, что некий поддомен надо добавить - факт обращения посетителя к серверу по адресу "http://некийновыйподдомен.webwarper.net/путь/..." Пока этот некийновыйподдомен не создан и не зарегистрирован ни в каком DNS, как я вообще узнаю, что пользователь его набрал в своем броузере? Разве информация дойдет до какого-то скрипта на моем сервере? А если и дойдет (что очень интересно!), я же не могу перенастраивать apache 10 раз в секунду. Тогда мне останется только писать собственный аналог веб-сервера (и заодно DNS), который бы ловил эти новые поддомены.

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

спустя 22 минуты [обр] Андрей Пахомов(0/310)[досье]
Пока этот некийновыйподдомен не создан и не зарегистрирован ни в каком DNS, как я вообще узнаю, что пользователь его набрал в своем броузере? Разве информация дойдет до какого-то скрипта на моем сервере? А если и дойдет (что очень интересно!), я же не могу перенастраивать apache 10 раз в секунду.

Вы ошибаетесь. Вам не надо настраивать 10 раз апач и ДНС. Все ДНС сервера ничего не знают о ваших поддменах, о них знает только ваш ДНС сервер, поэтому все запросы о любом поддомене будут идти на ваш ДНС сервер. как его настроить я уже писал: добавить в ваш ДНС запись следующего вида:

* IN A webwarper.com
или 
* IN CNAME webwarper.com

и он честно для всех поддоменов будет отдавать IP вашего сервера.
А чтобы апач разбирал ваши поддомены - это можно сделать через mod_rewrite. Все то делается один раз и больше никогда не меняется.

спустя 1 час 2 минуты [обр] Даниэль Алиевский(9/125)[досье]

Андрей Пахомов[досье]
Спасибо! Вот этого мне не хватало. Я почему-то считал, что ничего не выйдет, и даже не стал копать глубже.

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

Пока же, разрешите вернуться к исходному вопросу. Можно ли уберечь кукисы, скажем, банально их переустанавливая снова и снова?

спустя 23 минуты [обр] Алексей Севрюков(0/1280)[досье]
Даниэль Алиевский[досье] AFAIK можно.
спустя 18 часов [обр] Даниэль Алиевский(9/125)[досье]

Алексей Севрюков[досье] Спасибо.
Уважаемые Сергей Круглов[досье], Андрей Пахомов[досье], еще раз спасибо за разъяснения по поводу реализации поддоменов, однако сформулированную задачу это решить не помогает. Как-то сразу не сообразил.

У меня уже есть минимум два домена: webwarper.net и www.webwarper.net. Первое, о чем я подумал, пытаясь решить поставленную задачу - зарезервировать один этих доменов (скажем, www.webwarper.net) для хранения собственных кукис, а посетителей на этот домен "не пускать". Но проблема в том, что кукисы, установленный в одном из доменов, в другом домене будут не видны - если только я не выставлю у кукисов соответствующий "domain=". Мне же требуется именно это: хранить управляющую информацию для обработки страниц с других сайтов (скажем, флаг наличия рекламы). Передать информацию из cookies через JavaScript тривиальным присваиванием тоже не получится (модель безопасности не позволит), пока я не присвою document.domain="webwarper.net". А стоит мне указать domain=webwarper.net в кукисе или JavaScript, как мы вернемся к исходному общему ограничению 20 cookies/domain. Разве не так?

JavaScript, конечно, в принципе позволяет решить задачу, как я уже описал (вариант #2). Громоздко, неудобно и с поеданием трафика.

Припоминаю, когда анонсировали MSIE 5.0, было много разговоров по поводу каких-то persistent-объектов в MSIE - как я понял, развитие идеи cookie, но с возможностью хранить большие объемы данных. К сожалению, мне тогда не удалось добиться, чтобы это заработало. Может быть, кто-нибудь пользовался? Или это давно умершая технология?

спустя 1 час 25 минут [обр] wiktar(0/20)[досье]

Простите за неответ по теме, но у меня вопрос:
разве не правильнее и проще было бы организовать работу WW как через прокси?

Ну, или хотябы для зарегистрированных пользователей. Отпадает проблема куки и даже авторизации. Адреса станут прозрачными, а не ww/~...

спустя 1 час 30 минут [обр] Александр Самойлов(3/342)[досье]
спустя 14 минут [обр] Даниэль Алиевский(9/125)[досье]

wiktar[досье]
Частый вопрос, однако :) Конечно, правильнее. Проблема лишь в том, что это уже сделано, причем в множестве продуктов. Взять хотя бы http://webaccelerator.google.com/ Какой смысл здесь конкурировать? Понятно, что Google трудно обогнать.
У меня другая ниша - продукт, не требующий инсталляции (не считая примитивной утилитки), который легко применить не ко всем сайтам сразу, а лишь к тем, где это удобно и полезно. Конкурирую за счет очень изощренного алгоритма коррекции HTML - по моим наблюдениям, он лучше тех, которые применяют известные системы online-перевода сайтов или анонимайзеры.
Извиняюсь за оффтопик.

Александр Самойлов[досье]
Конечно, я там был :) Сходу оно у меня не заработало. А в последние годы об этой технологии вообще ничего не слышно (в частности, здесь, на xpoint). Что меня и насторожило - стоит ли этим пользоваться? Знаете ли вы, скажем, сайты, где это применяется?

спустя 27 минут [обр] Александр Самойлов(3/342)[досье]
Даниэль Алиевский[досье]
Могло не заработать, если в IE Security Settings > Userdata Persistence > Disable.
спустя 25 минут [обр] Даниэль Алиевский(9/125)[досье]
Да нет, оно enable по умолчанию. Впрочем, спасибо, не надо обсуждать, почему оно не работает - раз я сейчас экспериментов не провожу. Любопытны общие впечатления и соображения по этому поводу.
спустя 3 часа 30 минут [обр] wiktar(0/20)[досье]

Даниэль Алиевский[досье] я не понимаю, если честно :)

Ваш сервис получает страницу из интернета, сжимает её gzip-ом и отдает пользователю?

Ну так здесь самый правильный способ - это работать в качестве прокси-сервера! Вся настройка пользователя сводиться к установке прокси на ваш.

Не нужно даже изменять адреса - всё-равно всё идёт через вас.

Никаких ограничений на куки, вообще никаких проблем :).

Единственное что - либо встраивать баннеры в отдаваемый html, либо давать сервис через прокси только зарегистрированным пользователям.

Не критикую вас, а лишь хочу понять свою ошибку - каких минусов (кроме конкуренции) я не замечаю?

спустя 1 час 9 минут [обр] Даниэль Алиевский(9/125)[досье]

wiktar[досье] Получим ведь от модератора по заслугам :)

Нет у вас ошибок. Я же сказал: прокси - совершенно правильная и грамотная реализация. И единственный минус - это наличие конкуренции. Вполне достаточно :) На данном этапе популярности и раскрученности WebWarper-у довольно сложно на этом заработать. Хотя, конечно, в планах это есть.

В любом продукте, в том числе в WebWarper-е, можно многое улучшить. Однако ж в первую очередь логично улучшать то, что требует минииум работы при максимуме эффекта и "пользы для общества". Например, есть в планах сжатие картинок, вырезание баннеров, доработки анти-анонимайзера и много другое. Вариант в виде прокси, хотя и улучшит мой сервис, очевидно, никакой "пользы для общества" не принесет, раз нечто подобное уже есть у Google и многих других.

Сделать домены вроде google.com.webwarper.net, если верить уважаемым коллегам, довольно просто. А прокси - это все равно инсталлируемая утилита, то есть продукт, требующий "упаковки", дизайна, документации и всего прочего. Кстати, уже некоторые сторонние разработчики начинают делать подобные продукты - хотя бы http://www.download.ru/search.ehtml?l=0&t=3&c=0&q=webproxy

спустя 4 дня [обр] Владимир Палант(49/4445)[досье]
Вот пример, где это реализовано: http://www.google.com.nyud.net:8090/ или http://xpoint.ru.nyud.net:8090/
спустя 4 минуты [обр] Владимир Палант(49/4445)[досье]
PS: Прокси — не обязательно "инсталлируемая утилита", незачем ставить его на компьютер пользователя. Можно сделать webwarper.net прокси-сервером, который будет достаточно прописать в настройках браузера. С комбинацией mod_proxy и mod_rewrite перенаправить запросы к прокси на ваши обычные скрипты для обработки запросов не должно быть особой проблемой.
спустя 8 дней [обр] Nikolay M. Didenko[досье]

Даниэль Алиевский[досье]
А можно узнать как вы собираетесь проделать 2 вариант, предложенный вами.
А именно вот это?????

загрузить в другой IFRAME скрипт из исходного домена, передав ему cookies в параметрах. А тот уже будет обладать правами, чтобы сообщить значение в исходную страницу

рассмотрим IE6 (скорее всего и IE5 тоже) при настройках по-умолчанию

  1. доступ к documentu основного скрипта из фрейма IE не даст. (а чтобы обратиться к другому фрйему, судя по иерархии надо обратится именно через родителя.)
  2. кука на другой домен через IFRAME не поставиться.

если бы эти два пункта были неверными - это была бы дырень в безопасности.
2 пункт проверен - на 100% не работает.
1 пункт не проверял, но делал почти тоже самое - доступа нет.

Мне бы было очень интересно увидеть реализацю этого метода. Если он все же возможен.

спустя 3 часа 31 минуту [обр] Александр Самойлов(3/342)[досье]
Nikolay M. Didenko[досье]
document.domain
спустя 1 день 3 часа [обр] Nikolay M. Didenko[досье]

Александр Самойлов[досье]
document.domain

непонял. пробовал выставлять это свойство, но ниче не получилось.
вот нашел в доке, что по этому поводу написано:

Нostname сервера, который обслуживал документ. Если документы от различных серверов в одном и том же домене обмениваются содержанием друг с другом, свойство domain обоих документов должны быть установлены на один и тот же домен, чтобы избежать ограничений защиты. Обычно если главные компьютеры не согласовываны, JavaScript отменяет доступ к данным формы другого документа. Это свойство позволяет, например, странице от сервера WWW связываться со страницей, обслуживаемой secure сервером.
Пример:
document.domain = "megaCorp.com"

Если не сложно, разьясните, пожалуйста. Как все таки мне получить доступ к фрейму из документа или обратно??? (если они с разных доменов)

спустя 1 час 23 минуты [обр] Сергей Круглов(33/2057)[досье]
у них должны быть одинаковыми первые 2 уровня домена (aaa.xxx.ru и bbb.xxx.ru) и оба должну у себя прописать document.domain="xxx.ru"
спустя 21 час [обр] Даниэль Алиевский(9/125)[досье]

Nikolay M. Didenko[досье] Может быть, я несколько туманно сформулировал.
Метод таков.
Имеем страницу: webwarper.net/a.htm.
Страница a.htm желает записывать и считывать куки из чужого для нее домена algart.net.
Для этого в a.htm размещаем два IFRAME-а - назовем их "iframeEx" и "iframeIn" - и создаем две специальные страницы algart.net/b.htm и webwarper.net/c.htm.

  1. Процедура установки куки XXXXXX. Выполняем
window.open("http://algart.net/b.htm?setcookie="+escape(XXXXX), "iframeEx");

Страница b.htm открывается в IFRAME-е iframeEx. Содержащийся в b.htm JavaScript-код (или, если угодно, серверный скрипт b.htm) анализирует параметр после ? и запоминает в домене algart.net нужную куку XXXXXX.

  1. Процедура чтения куки. Выполняем
window.open("http://algart.net/b.htm?readcookie="+имя_куки, "iframeEx");

В ответ JavaScript-код, содержащийся в b.htm, читает соответствующую куку XXXXXX (хранящуюся в домене algart.net!) и сразу же выполняет

window.open("http://webwarper.net/c.htm?cookie="+escape(XXXXXX), "iframeIn");

JavaScript-код в файле c.htm, прочитав параметр cookie после ?, уже имеет все права, чтобы передать прочитанное значение в страницу a.htm - например, установив top.loadedCookieValue=XXXXXX.

Вроде должно работать. Только вот требует бессмысленной траты трафика на подгрузку страниц b и c и ничего не дает, пока эти страницы не загрузятся в iframe-ы. Скажем, прочитать куку в процессе формирования страницы a.htm таким образом нельзя.

Powered by POEM™ Engine Copyright © 2002-2005