Comments 43
Хорошая статья, спасибо.
Я слыхал о скрипте PersistJS (http://pablotron.org/?cid=1557 или тут по-русски http://www.jstoolbox.com/2008/05/22/persistjs-sessii-v-javascript-bez-cookies/) - он автоматически определяет, какой способ доступен, globalstorage либо userdata, либо что-то еще. Если вообще ничего не доступно, то флэш используется.
Я слыхал о скрипте PersistJS (http://pablotron.org/?cid=1557 или тут по-русски http://www.jstoolbox.com/2008/05/22/persistjs-sessii-v-javascript-bez-cookies/) - он автоматически определяет, какой способ доступен, globalstorage либо userdata, либо что-то еще. Если вообще ничего не доступно, то флэш используется.
+2
Уж очень не удобно в реальности работать с этим. Все же проще будет хранить данные превыщающие 2 кб на сервере в базе, а в куках хранить их идетификатор.
+1
Смотря для каких целей, к примеру этим способом можно делать авто сохранение текста набранного пользователем, не обращаясь каждый раз к серверу и не тратя попусту пользовательский трафик, либо банить нарушителей. Чистку кукисов, смену айпишника, заход через прокси умеют многие, а почистить такое будет трудновато
+1
Нарушитель может сменить браузер. Или написать в строке адреса (FireBug'е, DOM Inspector'е,...) javascript:код_удаления
0
Была статья про хранение данных в window.name, кроссбраузерно, данных тоже прилично вмещало.
+1
хороший способ. только далеко не всегда пользователь должени видеть подобного рода информацию.
ИМХО проще создать сессию и хранить неограниченное количество информации на сервере.
ИМХО проще создать сессию и хранить неограниченное количество информации на сервере.
0
UFO just landed and posted this here
Автор, конечно, молодец. Но лично я бы не стал хранить на клиенте 100 кб данных :DDD Чем меньше, тем лучше.
0
Не 2 кб, а 4 кб ;)
А еще есть возможность использовать flash storage.
А еще есть возможность использовать flash storage.
+1
у вас опечатка storage.['hello']
+1
> но ограничение хранения данных в размере не более 2kb не всех радует, сегодня если позволите я вам расскажу как посредством Java Script хранить около 100kb на клиенте.
Во-первых, ограничение не 2Kb, а 4Kb на куку. Во-вторых, на одном домене можно одновременно иметь до 20 кук включительно. Итого, суммарно, можно, используя механизм Cookies, оперировать 80Kb. А еще можно сжимать данные, таким образом хранить больший объем данных в этих доступных 80Kb.
Но в любом случае я согласен, что большие объемы данных в куках держать глупо, так как все эти данные будут отправляться на сервер при каждом реквесте.
Во-первых, ограничение не 2Kb, а 4Kb на куку. Во-вторых, на одном домене можно одновременно иметь до 20 кук включительно. Итого, суммарно, можно, используя механизм Cookies, оперировать 80Kb. А еще можно сжимать данные, таким образом хранить больший объем данных в этих доступных 80Kb.
Но в любом случае я согласен, что большие объемы данных в куках держать глупо, так как все эти данные будут отправляться на сервер при каждом реквесте.
-1
насколько я помню, ограничение кук всё-таки 4 кб на домен, а не на куку
0
И все-таки, 4 кб на куку, а не на домен. Пожалуйста, посмотрите спецификацию.
-1
For one domain name, each cookie is limited to 4,096 bytes. This total can exist as one name-value pair of 4 kilobytes (KB) or as up to 20 name-value pairs that total 4 KB.
http://support.microsoft.com/kb/306070
кукой они называют всю строчку, а не одну пару ключ-значение
http://support.microsoft.com/kb/306070
кукой они называют всю строчку, а не одну пару ключ-значение
+2
Спасибо за ссылку, признаю свою неправоту. Спека, которой я пользовался, http://www.w3.org/Protocols/rfc2109/rfc2… (пункт 6.3) не говорит об этом прямо, и лишь дополнительная информация по приведенной Вами ссылке проясняет этот момент.
0
вообще ваша спека уже перекрыта следующей версией RFC 2965
и обе RFC используют термин cookie для обозначения вообще всей сессионной информации
и обе RFC используют термин cookie для обозначения вообще всей сессионной информации
0
А вот насчет последнего я не уверен. Как тогда это понимать (из того же пункта 6.3, кстати это цитируется в приведенной Вами ссылке): "at least 20 cookies per unique host or domain name"? Как раз это и сбивает с толку, и вносит путаницу что они называют термином cookie - то ли одну пару ключ-значение, то ли "всю сессионную информацию"?
0
да, не очень удачно спека написана : (
0
Забавно. Только что поставил эксперимент, использовал 3 браузера - IE7, FF2 и Opera 9.27. Результаты, мягко скажем, неожиданные, и отличается от того, что в спецификации:
1. IE и FF позволяют работать с 50 куками (парами ключ-значение).
2. Opara позволяет работать только с 30 куками.
3. Все три браузера принимают куки, суммарный размер которых больше чем 4 килобайта (как раз максимум по 4 килобайта на каждую, как в спеке), и сохраняет их на диске в полном объеме.
4. Opera, когда посылает респонс, отправляет куки серверу только пока суммарный их размер не превышает 4 килобайта. Если суммарный размер кук больше, то отправляются только первые из них, суммарный размер которых в пределах 4 килобайт.
5. IE и FF пытаются отправить серверу все куки что есть, игнорируя размеры. При этом сервер (в моем случае Apache 1.3) ругается на неправильный заголовок, мол, превышен размер.
Итак, вывод из этой лабораторной работы. Спека - это одно, а на практике оказывается, как обычно, производители браузеров ей не очень следуют.
1. IE и FF позволяют работать с 50 куками (парами ключ-значение).
2. Opara позволяет работать только с 30 куками.
3. Все три браузера принимают куки, суммарный размер которых больше чем 4 килобайта (как раз максимум по 4 килобайта на каждую, как в спеке), и сохраняет их на диске в полном объеме.
4. Opera, когда посылает респонс, отправляет куки серверу только пока суммарный их размер не превышает 4 килобайта. Если суммарный размер кук больше, то отправляются только первые из них, суммарный размер которых в пределах 4 килобайт.
5. IE и FF пытаются отправить серверу все куки что есть, игнорируя размеры. При этом сервер (в моем случае Apache 1.3) ругается на неправильный заголовок, мол, превышен размер.
Итак, вывод из этой лабораторной работы. Спека - это одно, а на практике оказывается, как обычно, производители браузеров ей не очень следуют.
0
Опечатка: Opera, когда посылает реквест*, ...
0
Также, имеется в виду, что работа ведется с одним доменом.
0
Спасибо за обзор, поправил в статье значение на 4 килобайта, мой источник подхромал.
0
ну да, все работают по-разному, разработчикам приходится полагаться на наименьший общий знаменатель
0
Если хранить данные клиента в базе данных, то в принципе можно с ними работать через Request.
То есть создать методы (сервер-сайд)
сreateCookie()
setCookieData($keyName,$value)
getCookieData()
removeCookie()
сreateCookie() - создает запись в таблице и возвращает уникальный ид который мы и будем хранить в обычной куке.
дальше посредством setCookieData($keyName,$value) сохраняем данные в таблице и посредством getCookieData() достаём массив данных.
Когда нам это всё больше не нужно, вызываем removeCookie() который стирает запись из таблицы.
Естественно надо продумать механизм безовастности.
То есть создать методы (сервер-сайд)
сreateCookie()
setCookieData($keyName,$value)
getCookieData()
removeCookie()
сreateCookie() - создает запись в таблице и возвращает уникальный ид который мы и будем хранить в обычной куке.
дальше посредством setCookieData($keyName,$value) сохраняем данные в таблице и посредством getCookieData() достаём массив данных.
Когда нам это всё больше не нужно, вызываем removeCookie() который стирает запись из таблицы.
Естественно надо продумать механизм безовастности.
0
В этом случае еще проблемой будет кроссбраузерность, ведь куки у каждого браузера свои
0
а в других случаях, что нет?
0
Я просто предлагаю хранить данные на клиенте посредством браузеров, а для кросс браузерности использовать мост через Local SharedObject от флеша поддерживаемым всеми браузерами где установлен флеш, это позволит синхронизировать данные между всеми браузерами и с большей мощью использовать хранилище. Мне тут еще подсказали что помимо флеша, такой мост можно организовать посредством Google Gears либо Adobe Air, о чем я забыл упомянуть в своей статье.
+1
Вот, теперь сайтам нужно полноценное хранилище данный на клиенте.
Всё больше нужны нормальные инструменты создания интерфейсов (окон и проч.), кроссбраузерно и по стандарту.
Будущее веба в изолированных веб-приложениях?
И хранилище, и отрисовка окон и прочих элементов, и ещё что-нибудь?
Очень мне хочется, чтоб вэб интерфейсы перешли вот в такие изолированные веб-приложения.
Всё больше нужны нормальные инструменты создания интерфейсов (окон и проч.), кроссбраузерно и по стандарту.
Будущее веба в изолированных веб-приложениях?
И хранилище, и отрисовка окон и прочих элементов, и ещё что-нибудь?
Очень мне хочется, чтоб вэб интерфейсы перешли вот в такие изолированные веб-приложения.
0
Раз уж упомянута возможность хранить данные в Silverlight Isolated Storage, то стоило бы вспомнить и про google gears.
+1
возможно не совсем по теме, но в флеше существует какая то бага при работе с сессиями, в альтернативных експлореру браузерах. По непонятных мне причинам флеш по умолчанию запрашивает кукиз из папки експлорера.
Тут описан пример: http://swfupload.org/forum/generaldiscus…
Тут описан пример: http://swfupload.org/forum/generaldiscus…
0
Sign up to leave a comment.
Альтернатива cookies посредством Java Script