Как стать автором
Обновить

Комментарии 43

Хорошая статья, спасибо.
Я слыхал о скрипте PersistJS (http://pablotron.org/?cid=1557 или тут по-русски http://www.jstoolbox.com/2008/05/22/persistjs-sessii-v-javascript-bez-cookies/) - он автоматически определяет, какой способ доступен, globalstorage либо userdata, либо что-то еще. Если вообще ничего не доступно, то флэш используется.
Уж очень не удобно в реальности работать с этим. Все же проще будет хранить данные превыщающие 2 кб на сервере в базе, а в куках хранить их идетификатор.
Смотря для каких целей, к примеру этим способом можно делать авто сохранение текста набранного пользователем, не обращаясь каждый раз к серверу и не тратя попусту пользовательский трафик, либо банить нарушителей. Чистку кукисов, смену айпишника, заход через прокси умеют многие, а почистить такое будет трудновато
Нарушитель может сменить браузер. Или написать в строке адреса (FireBug'е, DOM Inspector'е,...) javascript:код_удаления
Так я же говорил про кросс браузерность, тоесть флеш был бы мостом между браузерами, конешно не спорю што обойти можно все, но такой подход пока што новый, поэтому пока пользователи догадаются контролировать порядок можно
Была статья про хранение данных в window.name, кроссбраузерно, данных тоже прилично вмещало.
Недостаток window.name в том, что если открыть ссылку в новом окне, то там сохраненные данные не доступны.
хороший способ. только далеко не всегда пользователь должени видеть подобного рода информацию.
ИМХО проще создать сессию и хранить неограниченное количество информации на сервере.
1. Использование локального хранилища позволяет организовать обмен данным между окнами браузера (причём не важно, как эти окна были открыты и что с ними происходило)
2. Можно сохранять данные пользователя даже в offline
НЛО прилетело и опубликовало эту надпись здесь
Автор, конечно, молодец. Но лично я бы не стал хранить на клиенте 100 кб данных :DDD Чем меньше, тем лучше.
так можно хранить и меньше =) цель статьи была донести до пользователей что cookies не единственный вид хранения данных на клиенте
Не 2 кб, а 4 кб ;)
А еще есть возможность использовать flash storage.
Так я же про flash storage писал, читай подзаголовок Local SharedObject
у вас опечатка storage.['hello']
Спасибо, поправил
НЛО прилетело и опубликовало эту надпись здесь
Простите, вы о чем?
+1

вообще, грамматических ошибок много: "об етом не нашол"
Увы русскому меня никто не учил, приходится учится на своих ошибках, вы меня поправляйте если что, всегда рад замечаниям.
> но ограничение хранения данных в размере не более 2kb не всех радует, сегодня если позволите я вам расскажу как посредством Java Script хранить около 100kb на клиенте.

Во-первых, ограничение не 2Kb, а 4Kb на куку. Во-вторых, на одном домене можно одновременно иметь до 20 кук включительно. Итого, суммарно, можно, используя механизм Cookies, оперировать 80Kb. А еще можно сжимать данные, таким образом хранить больший объем данных в этих доступных 80Kb.

Но в любом случае я согласен, что большие объемы данных в куках держать глупо, так как все эти данные будут отправляться на сервер при каждом реквесте.
насколько я помню, ограничение кук всё-таки 4 кб на домен, а не на куку
И все-таки, 4 кб на куку, а не на домен. Пожалуйста, посмотрите спецификацию.
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://www.w3.org/Protocols/rfc2109/rfc2… (пункт 6.3) не говорит об этом прямо, и лишь дополнительная информация по приведенной Вами ссылке проясняет этот момент.
вообще ваша спека уже перекрыта следующей версией RFC 2965

и обе RFC используют термин cookie для обозначения вообще всей сессионной информации
А вот насчет последнего я не уверен. Как тогда это понимать (из того же пункта 6.3, кстати это цитируется в приведенной Вами ссылке): "at least 20 cookies per unique host or domain name"? Как раз это и сбивает с толку, и вносит путаницу что они называют термином cookie - то ли одну пару ключ-значение, то ли "всю сессионную информацию"?
да, не очень удачно спека написана : (
Забавно. Только что поставил эксперимент, использовал 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) ругается на неправильный заголовок, мол, превышен размер.

Итак, вывод из этой лабораторной работы. Спека - это одно, а на практике оказывается, как обычно, производители браузеров ей не очень следуют.
Опечатка: Opera, когда посылает реквест*, ...
Также, имеется в виду, что работа ведется с одним доменом.
Спасибо за обзор, поправил в статье значение на 4 килобайта, мой источник подхромал.
Да я сам сегодня про куки много нового узнал, век живи - век учись, как говорится...
ну да, все работают по-разному, разработчикам приходится полагаться на наименьший общий знаменатель
Если хранить данные клиента в базе данных, то в принципе можно с ними работать через Request.

То есть создать методы (сервер-сайд)
сreateCookie()
setCookieData($keyName,$value)
getCookieData()
removeCookie()

сreateCookie() - создает запись в таблице и возвращает уникальный ид который мы и будем хранить в обычной куке.
дальше посредством setCookieData($keyName,$value) сохраняем данные в таблице и посредством getCookieData() достаём массив данных.
Когда нам это всё больше не нужно, вызываем removeCookie() который стирает запись из таблицы.

Естественно надо продумать механизм безовастности.
В этом случае еще проблемой будет кроссбраузерность, ведь куки у каждого браузера свои
а в других случаях, что нет?
Я просто предлагаю хранить данные на клиенте посредством браузеров, а для кросс браузерности использовать мост через Local SharedObject от флеша поддерживаемым всеми браузерами где установлен флеш, это позволит синхронизировать данные между всеми браузерами и с большей мощью использовать хранилище. Мне тут еще подсказали что помимо флеша, такой мост можно организовать посредством Google Gears либо Adobe Air, о чем я забыл упомянуть в своей статье.
Вот, теперь сайтам нужно полноценное хранилище данный на клиенте.
Всё больше нужны нормальные инструменты создания интерфейсов (окон и проч.), кроссбраузерно и по стандарту.

Будущее веба в изолированных веб-приложениях?
И хранилище, и отрисовка окон и прочих элементов, и ещё что-нибудь?

Очень мне хочется, чтоб вэб интерфейсы перешли вот в такие изолированные веб-приложения.
ну, статические сайты уже стали прошлым веком, разработчики сейчас пытаются как можно больше в страницы донести динамики и UI. И я думаю чем меньше клиент обращается к серверу, но в ту же очередь в полную мощь использует веб-приложение и динамику тем лутше.
Раз уж упомянута возможность хранить данные в Silverlight Isolated Storage, то стоило бы вспомнить и про google gears.
Точно, и еще я видимо забыл про Adobe AIR.
возможно не совсем по теме, но в флеше существует какая то бага при работе с сессиями, в альтернативных експлореру браузерах. По непонятных мне причинам флеш по умолчанию запрашивает кукиз из папки експлорера.
Тут описан пример: http://swfupload.org/forum/generaldiscus…
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории