Следует ли избегать использования файлов cookie, если это возможно?

Question

Не удается ли получить файл cookie пользователя и получить его значение в качестве переменной PHP, чем для получения переменной сеанса?

Answer 1

Нет. В чистых технических терминах это, скорее всего, обратное, так как для инициализации сеанса будет немного незначительных накладных расходов.

Данные cookie поступают как часть HTTP-запроса независимо от того, что, и PHP читает его в $ _COOKIE по умолчанию. Так что это всегда будет. $ _SESSION требует, чтобы вы в какой-то момент вызывали session_start().

Однако разница в производительности между двумя будет нелепо малой и не стоит беспокоиться.

Answer 2

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

С точки зрения безопасности, действительно ли вы хотите хранить информацию на стороне клиента? Как правило, я не буду хранить вещи с клиентом.

Answer 3

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

Использовать только $_SESSION вместо того, чтобы изобретать его с помощью «пользовательского cookie».

Answer 4

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

Однако Вы должны быть осведомлены о различиях между ними:

• Сессии хранятся на сервере, а это значит, клиенты не имеют доступа к информации, которую вы храните о них. Данные сеанса, хранящиеся на вашем сервере, не должны передаваться полностью с каждой страницы; клиентам просто нужно отправить идентификатор, и данные загружаются с сервера.

• С другой стороны, Cookies хранятся на клиенте. Они могут быть прочными в течение длительного времени и позволят вам работать более плавно, когда у вас есть кластер веб-серверов. Однако, в отличие от сеансов, данные, хранящиеся в файлах cookie, полностью передаются с каждым запросом страницы.

Answer 5

В некоторых браузере это не представляется возможным хранить куки, чтобы избежать этой проблемы, вы можете передать (SID идентификатором сессии) или какие-то скрытые, заполнены значения TextBox, а не печенье, используя GET и методы POST ,

Answer 6

Хотя примерно эквивалент с точки зрения манипуляций в коде, файлы cookie и переменные сеанса очень разные.

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

Сессионные переменные, с другой стороны, имеют свои собственные проблемы. Поскольку они хранятся в контексте сервера, они не распространяются между кластерными серверами.Если сервер/служба сбрасывается или сеанс пользователя заканчивается, все, что было сохранено в коллекции session [], теряется. Сохранение больших данных в переменной сеанса приводит к снижению производительности на сервере, что может стать очень плохим, если у вас много трафика. Для переменных сеанса требуется файл cookie, который сервер использует для идентификации сеанса пользователя. Это возможно для пользователя, чтобы изменить их кук, чтобы получить доступ к данным, хранящимся в других сеансах, хотя это было бы довольно Freakin' трудно сделать с любым типом значения, так как идентификатор сессии случайным образом, бессмысленные идентификаторами псевдо.

В конечном счете, все это дерьмо должны храниться в базе данных в любом случае. Сессии - это ленивое удобство, которого следует избегать при разработке любого надежного приложения. Куки-файлы должны использоваться минимально - как правило, я храню указатель в файле cookie, который помогает мне идентифицировать пользователя (похожий на cookie sessionID, но специфичный для приложения), но все остальное идет в базе данных. Это дает вам доступность серверных агностиков, безопасное хранилище, срок службы данных, установленные вашим приложением, а не конфигурацию сервера, хорошую возможность запроса и отчета и т. Д.

Базы данных легко выполняются правильно. Там не много, много причин, что любая информация о состоянии вы собираете должна храниться в базе данных, и нет веских причин не к.