В одной строке: maplist(atom_number,L,LO)
с использованием maplist/3
и atom_number/2
.
Определенно не пароли! Или что-либо чувствительное... помнит, что cookie хранятся на компьютерах людей так с Вашей точки зрения (как разработчик веб-сайта), они в основном отсутствуют в дикой природе, потенциально доступной для любого.
Обычная практика должна просто сохранить идентификатор сессии в cookie и хранить всю другую релевантную информацию в базе данных (или файл, или безотносительно) на сервере, индексированном идентификатором сессии.
Одно предложение - то, что Вы не храните любые ключи к своей базе данных в cookie. т.е. адреса электронной почты, идентификатор столбца и т.д. Если так, необходимо зашифровать данные.
Ничего не храните в Cookie, который позволит Вашему сайту быть взломанным или полученным доступ, не проходя надлежащие каналы. Обычно, просто идентификатор сессии или идентификатор пользователя хранятся в cookie, и часто в форме намеревался быть непрозрачным любому, но потребителю cookie.
Я постарался бы не хранить что-либо, что, если изменено, поставит под угрозу функциональность сайта.
Так, храня что-то как идентификатор пользователя, цены объектов корзины, пароль, пользовательские роли, и т.д. проблематичен. Я сохраняю такого рода вещь в данных сессии пользователя по серверу.
Храня имя пользователя или информацию о профиле (только в целях дисплея), предпочтения настройки (цвета, текст, безотносительно) прекрасны.
Намного легче ответить, что не приемлемо сохранить в cookie. Что-либо, что должно остаться безопасным, не должно быть сохранено. Это включает пароли, номера кредитных карт, номера социального страхования, и т.д.
Я думаю, что это должно хорошо сохранить имя для входа в систему пользователя, так как та информация действительно не является уязвимой. Предпочтительные настройки пользователя для Вашего сайта должны быть хорошо также.
Помните, cookie являются просто текстовыми файлами, которые кто-то (или некоторое приложение) может открыть и считать или записать, таким образом, Вы не должны доверять информации, Вы получаете от cookie, также. Санируйте его точно так же, как любой другой ввод данных пользователем.
Хорошо кроме чувствительных и связанных с безопасностью данных действительно нет никакого предела тому, что Вы не можете и можете сохранить, но просто помнить, что, если те данные не сохраняются на стороне сервера, они могли бы быть потеряны в целом, и нужно предположить, что, если пользователь удаляет cookie, они не причинят беспокойство ему слишком много для восстановления его настроек/конфигурации. Нет никаких инструкций кроме использования хорошего здравого смысла здесь.
Существуют однако пределы cookie. Вы не должны превышать 19 cookie на домен, и никакой cookie не должен быть больше, чем 4 КБ (4 096 байтов) согласно пределам IE:
Каждый cookie начинается с пары "имя-значение". Эта пара сопровождается нулем или большим количеством пар значения атрибута, которые разделяются точками с запятой. Для одного доменного имени каждый cookie ограничен 4 096 байтами. Это общее количество может существовать как одна пара "имя-значение" 4 килобайтов (КБ) или максимум как 20 пар "имя-значение" те общие 4 КБ. Если компьютер не имеет достаточного пространства для хранения cookie, cookie отбрасывается. Это не является усеченным. Приложения должны использовать как можно меньше cookie и максимально маленький cookie. Кроме того, приложения должны смочь обработать потерю cookie.
Если веб-приложение использует больше чем 19 пользовательских cookie, состояние сеанса ASP может быть потеряно. Internet Explorer 4.0 и более поздние версии разрешают в общей сложности 20 куки для каждого домена. Поскольку ASPSessionID является cookie при использовании 20 или больше пользовательских cookie браузер вынужден отбросить ASPSessionID cookie и проиграть сессию.