Форум PHP

Слегка дополню.

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

Это так в большинстве случаев.
Однако внутрисеансовые кукисы (с коротким временем жизни) тоже могут с успехом применяться, если хранить данные в сессиях а)бесполезно или б)неудобно.

Пример а) - хранение аутентифицирующих пользователя данных внутри сеанса. Стойкость к атакам такого метода аутентификации куда выше обычных. А держать authentication tokens в сессии бесполезно (а значит вредно), поскольку чтобы играть хоть какую-то роль в процессе, они должны сообщаться серверу клиентом, а не переноситься внутри сервера.

Случай б) - такое распределение программной логики, когда с данными посетителя основную активную работу выполняет слой тонкого клиента (проще говоря, JavaScript) всей программной архитектуры. Примером может служить интернет-магазин с корзиной написанной на JavaScript. Пока посетитель оперирует с корзиной покупок, все вычисления делаются на клиентской стороне. Окончательно сформированный заказ выкидывается на сервер для проверки и подтверждения. Естественно, JS слой добраться до кукисов может мгновенно, до сессии ему дотянуться куда проблематичнее - тут уже потребуется ajax с его серверной поддержкой.

>Да, сессии хранят данные на сервере, а cookie на машине клиента, т.е. в случае сессии обеспечить безопасность данных проще, чем в случае cookie. Однако, злоумышленик может похитить и SID-сессии и выдать себя за владельца данных.

Я бы сказал по-другому.
Да, сессии хранят данные на сервере, а cookie на машине клиента, но поскольку сама принадлежность сессии клиенту опирается либо на кукис либо на открытый GET/POST параметр, злоумышленик легко может похитить SID-сессии и выдать себя за владельца данных. Таким образом в случае сессии обеспечить безопасность данных не проще, а даже сложнее, чем в случае cookie, так как возникает еще один слой хранения данных, за устойчивость к атакам которого придется бороться.

А что вызывает затруднение? Сессии и куки не две разные альтернативы - они дополняют друг друга (более того, сессии используют cookie в работе). Когда вам требуется сохранять данные в течении сеанса или короткого времени (до часу) используются сессии, если вам требуется сохранять данные между сеансами и в течении длительного времени (до сотен дней) используются cookie. Не безопасность определяет выбор того или иного инструмента, а время жизни данных. Безопасность следует обеспечивать и в том и другом случае, тем более, что сессия использует cookie для своей работы. Да, сессии хранят данные на сервере, а cookie на машине клиента, т.е. в случае сессии обеспечить безопасность данных проще, чем в случае cookie. Однако, злоумышленик может похитить и SID-сессии и выдать себя за владельца данных.

Дело не в плюсах или минусах - дело во времени жизни данных - если они не потребуются при следующем сеансе - используются сессии, если потребуются - cookie.

Я смотрю здесь не один я запутался:))

Интересно, a cheops что скажет?

сессия безопасней тем что хранится меньше) -Вставте в setcookie параметр time=60,а в session lifetime значение 500000-увидите,что живет меньше...вроде же сессия хранится в куках или в передаваемой ссылке-в куках хранится не сессия,а идентификатор сессии,а сам сессионный файл хранится на сервере

Trianon
из-за чего злится то?)
просто он наверное имел в виду что сессия безопасней тем что хранится меньше) попробуй её успеть своровать... скопировать.. составить http запрос... хотя у меня окно браузера не закрывается часов по 10) хм пойду ка я пассы менять)))
кстати этой темой и меня запутали) вроде же сессия хранится в куках или в передаваемой ссылке(вроде php должен это делать, если куки у товарища отключены)

Вы меня заболтать решили?
Я не спрашивал, как надо переделать.
Я спросил, на основании чего Вы решили, что так называемая "безопасность" у сессии выше чем у её кукиса?

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

Зла не хватает.

Тогда можно сделать привязку сессии к IP. И вообще кукисы храняться на компьютере пользователя и в случае общего доступа к компьютеру подделать кукисы легче, чем сессии.
А еще пользователь может отключить кукисы и соответственно авторизация не будет работать. Мое мнение надо делать и на том, и на том одновремено

>Еще остается вопрос безопасности, т.е. считается, что сессии безопасней, в отличии от кукисов, которые можно подменить. Вот.

Если я подменю кукис (или get/post-параметр) сессионного ключа, как Вы думаете, что произойдет с Вашей безопасной сессией?

Использование сессий или кукисов, обусловлено, помимо безопасности, удобством для пользователя: сессии работают до того, пока не закроется окно браузера или вы их не обнулите принудительно, а если вы хотите, чтобы пользователю, вернувшись на ваш сайт, не пришлось логиниться по-новой - используйте кукисы. Еще остается вопрос безопасности, т.е. считается, что сессии безопасней, в отличии от кукисов, которые можно подменить. Вот.

В сессии аутентифицирующий токен держать бесполезно
Его хранить имеет смысл только в cookies. либо передавать явным или скрытым параметром в сложных случаях (wap и т.п.)

Просто в силу того, что имеющуюся сессию тоже придется чем-то аутентифицировать.