Меню Рубрики

Установка и чтение cookie php

Установка и чтение cookie php

Cookie (куки) представляют небольшие наборы данных (не более 4 кБайт), с помощью которых веб-сайт может сохранить на компьютере пользователя любую информацию. С помощью куки можно отслеживать активность пользователя на сайте: залогинен пользователь на сайте или нет, отслеживать историю его визитов и т.д.

Сохранение cookie

Для сохранения куки на компьютере пользователя используется функция setcookie(). Она имеет следующее определение:

Функция setcookie() может принимать следующие параметры:

name : имя cookie, которое будет использоваться для доступа к его значению

value : значение или содержимое cookie — любой алфавитно-цифровой текст не более 4 кБайт

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

path (необязательный параметр): путь к каталогу на сервере, для которого будут доступны cookie. Если задать ‘/’, cookie будут доступны для всего сайта. Если задать, например, ‘/mydir/’ , cookie будут доступны только из каталога /mydir/’ и всех его подкаталогов. По умолчанию значением является текущий каталог, в котором устанавливаются cookie.

domain (необязательный параметр): задает домен, для которого будут доступны cookie. Если это домен второго уровня, например, localhost.com, то cookie доступны для всего сайта localhost.com, в том числе и для его поддоменов типа blog.localhost.com.

Если задан поддомен blog.localhost.com, то cookie доступны только внутри этого поддомена.

secure (необязательный параметр): указывает на то, что значение cookie должно передаваться по протоколу HTTPS. Если задано true , cookie от клиента будет передано на сервер, только если установлено защищенное соединение. По умолчанию равно false .

httponly (необязательный параметр): если равно true , cookie будут доступны только через http протокол. То есть cookie в этом случае не будут доступны скриптовым языкам, например, JavaScript. По умолчанию параметр равен false

Здесь устанавливаются две куки: «city» и «language». Первая куки уничтожается после закрытия браузера, а вторая — через 3600 секунд, то есть через час

В cookie можно сохранить любую информацию, но не стоит сохранять важные с точки зрения безопасности данные, например, пароли. А если и сохранять какую-то важную информацию, то следует хранить ее в зашифрованном виде.

Получение cookie

Чтобы получить cookie, можно использовать глобальный ассоциативный массив $_COOKIE, например, $_COOKIE[«city»] . Так, получим ранее сохраненные куки:

Сохранение массивов в cookie

Сохранение в куки массивов имеет некоторые особенности. Например, сохраним следующий массив:

Теперь получим его и выведем на страницу:

Удаление cookie

Для удаления cookie достаточно в качестве срока действия указать какое-либо время в прошлом:

источник

Установка и чтение cookie php

Когда пользователь заходит на сайт, нам нужно определить его IP-адрес, найти в базе данных информацию о его посещениях, увеличить счетчик и вывести его в браузер посетителя. Написать обработчик (скрипт) подобной процедуры несложно. Однако при использовании такого метода у нас появляются проблемы следующего характера:

  • Для каждого IP-адреса нужно вести учет в одной таблице, которая может быть очень большой. А из этого следует, что мы нерационально используем процессорное время и дисковое пространство;
  • У большинства домашних пользователей IP-адреса являются динамическими. То есть, сегодня у него адрес 212.218.78.124, а завтра — 212.218.78.137. Таким образом, велика вероятность идентифицировать одного пользователя несколько раз.

Можно использовать второй способ, который намного легче в реализации и более эффективен. Мы устанавливаем в Cookie переменную, которая будет храниться на диске удаленного пользователя. Эта переменная и будет хранить информацию о посещениях. Она будет считываться скриптом при обращении посетителя к серверу. Выгода такого метода идентификации очевидна. Во-первых, нам не нужно хранить множество ненужной информации о IP-адресах. Во-вторых, нас не интересуют динамические IP-адреса, поскольку данные о своих посещениях хранятся конкретно у каждого посетителя сайта.

Теперь понятно, для чего мы можем использовать Cookie — для хранения небольшой по объему информации у клиента (посетителя) сайта, например: настройки сайта (цвет фона страниц, язык, оформление таблиц и.т.д.), а также другой информации.

Файлы Cookies представляют собой обыкновенные текстовые файлы, которые хранятся на диске у посетителей сайтов. Файлы Cookies и содержат ту информацию, которая была в них записана сервером.

Программирование Cookies

Приступим к программированию Cookies.

Для установки Cookies используется функция SetCookie(). Для этой функции можно указать шесть параметров, один из которых является обязательным:

  • name — задает имя (строк), закрепленное за Cookie;
  • value — определяет значение переменной (строка);
  • expire — время «жизни» переменной (целое число). Если данный параметр не указать, то Cookie будут «жить» до конца сессии, то есть до закрытия браузера. Если время указано, то, когда оно наступит, Cookie самоуничтожится.
  • path — путь к Cookie (строка);
  • domain — домен (строка). В качестве значения устанавливается имя хоста, с которого Cookie был установлен;
  • secure — передача Cookie через защищенное HTTPS-соединение.

Обычно используются только три первые параметра.

php

// Устанавливаем Cookie до конца сессии:
SetCookie ( «Test» , «Value» );

// Устанавливаем Cookie на один час после установки:
SetCookie ( «My_Cookie» , «Value» , time ()+ 3600 );

?>

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

php
// Устанавливаем Cookie до конца сессии:
// В случае успешной установки Cookie, функция SetCookie возвращает TRUE:
if ( SetCookie ( «Test» , «Value» )) echo «

Cookies успешно установлены!

Функция SetCookie() возвращает TRUE в случае успешной установки Cookie. В случае, если Cookie установить не удается SetCookie() возвратит FALSE и возможно, предупреждение (зависит от настроек PHP). Пример неудачной установки Cookie:

Читайте также:  Установка лобовых стекол выезд

php
// Cookies установить не удастся, поскольку перед отправкой
// заголовка Cookie мы выводим в браузер строку ‘Hello’:
echo «Hello» ;
// Функция SetCookie возвратит FALSE:
if ( SetCookie ( «Test» , «Value» )) echo «

Cookie успешно установлен!

Cookie установить не удалось!

Cookie установить не удалось, поскольку перед посылкой заголовка Cookie мы вывели в браузер строку «Hello».

Чтение значений Cookies

Получить доступ к Cookies и их значениям достаточно просто. Они хранятся в суперглобальных массивах и $_COOKIE и $HTTP_COOKIE_VARS .

Доступ к значениям осуществляется по имени установленных Cookies, например:

echo $_COOKIE[‘my_cookie’];
// Выводит значения установленной Cookie ‘My_Cookie’

Пример установки Cookie и последующего его чтения:

php
// Устанавливаем Cookie ‘test’ со значением ‘Hello’ на один час:
setcookie ( «test» , «Hello» , time ()+ 3600 );
// При следующем запросе скрипта выводит ‘Hello’:
echo @$ _COOKIE [ ‘test’ ];
?>

В рассмотренном примере при первом обращении к скрипту устанавливается Cookie «test» зо значением «hello». При повторном обращении к скрипту будет выведено значение Cookie «test», то есть строка «Hello».

При чтении значений Cookies обращайте внимание на проверку существования Cookies, например, используя оператор isset(). Либо путем подавления вывода ошибок опереатором @

А вот пример, как построить счетчик числа загрузок страницы с помощью Cookies:

php
// Проверяем, был ли уже установлен Cookie ‘Mortal’,
// Если да, то читаем его значение,
// И увеличиваем значение счетчика обращений к странице:
if ( isset ($ _COOKIE [ ‘Mortal’ ])) $ cnt =$ _COOKIE [ ‘Mortal’ ]+ 1 ;
else $ cnt = 0 ;
// Устанавливаем Cookie ‘Mortal’ зо значением счетчика,
// С временем «жизни» до 18/07/29,
// То есть на очень долгое время:
setcookie ( «Mortal» ,$ cnt , 0x6FFFFFFF );
// Выводит число посещений (загрузок) этой страницы:
echo «

Вы посещали эту страницу » .@$ _COOKIE [ ‘Mortal’ ]. « раз

Удаление Cookies

Иногда возникает необходимость удаления Cookies. Сделать это несложно, необходимо лишь вновь установить Cookie с идентичным именем и пустым параметром. Например:

php
// Удаляем Cookie ‘Test’:
SetCookie ( «Test» , «» );
?>

Установка массива Cookies и его чтение

Мы может установить массив Cookies, используя квадратные скобки в именах Cookies [] , а затем прочитать массив Cookies и значения этого массива:

php
// Устанавливаем массив Cookies:
setcookie ( «cookie[1]» , «Первый» );
setcookie ( «cookie[2]» , «Второй» );
setcookie ( «cookie[3]» , «Третий» );

// После перезагрузки страницы мы отобразим
// Состав массива Cookies ‘cookie’:
if ( isset ($ _COOKIE [ ‘cookie’ ])) <
foreach ($ _COOKIE [ ‘cookie’ ] as $ name => $ value ) <
echo «$name : $value
» ;
>
>
?>

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

источник

PHP Cookie — практические примеры использования

Привет, друзья. Пришло время поговорить о том, что такое PHP cookie, как их установить, удалить, перезаписать и где они используются. Этот урок для начинающих и полных чайников в программировании, поэтому буду показывать на конкретных практических примерах. Итак, что же такое куки в PHP? Это один из способов хранения определенных данных на стороне клиента. Если говорить проще, то куки хранятся в браузере пользователя. Например при авторизации. Когда юзер отправляет данные, они сохраняются на устройстве. Теперь давайте ближе к делу или сразу к видео

Как установить куки в PHP

Все не так сложно, как может показаться. Установка cookie происходит следующим образом:

Это базовые значения, которые обязательны для заполнения. Но параметров гораздо больше, а именно 7! Семь, Карл! И вот для чего каждый из них нужен.

1 Name Название (имя) cookie
2 Value Значение (как правило переменная)
3 Expires Время жизни куки
4 Path Путь для которого будут сохранены куки
5 Domain Можно указать поддомен (‘.domain.ru’)
6 Secure Использование только на HTTPS (true или false)
7 HttpOnly Использование только на HTTP (true или false)

В подавляющем большинстве случаев используются первые 3 параметра чтобы записать cookie в PHP. То есть имя, значение и время жизни. Этого вполне достаточно для полноценной работы. Давайте к практике.

Здесь я установил cookie name со значением — 5, которая удалится через 1 минуту.

Как получить, прочитать, проверить cookie в PHP

В этом нам поможет глобальный массив COOKIE. Чтобы получить значение куки нам нужно вызвать ее по имени.

Как вы уже догадались, на экран выведется пятерка. Теперь сделаем проверку. Если данная кука была установлена, то выедем одно сообщение, если не была, то другое.

Есть один маленький нюанс. При первом заходе на страницу будет выведено сообщение, что куки не установлены, однако, если заглянуть в консоль браузера, то увидим, что она там есть. В чем же дело? Элементарно. Дело в том, что запрос на проверку и сама установка куки идут ОДНОВРЕМЕННО. Поэтому сообщение об успешной установке мы увидим только после следующей перезагрузке страницы.

Теперь у нас есть условие и его можно использовать в некоторых случаях.

Авторизация с использованием PHP Cookie

Для примера я создам 2 формы. Первая с одним единственным полем, в которое будем писать свое имя. Пока не будет введено и отправлено имя, пользователю будут недоступны некоторые элементы страницы. То есть, если он не авторизован, то какие-то функции сайта от него будут скрыты, а так же показано приветствие. После того, как данные с формы будут отправлены, эта форма будет скрыта и показана другая, которая просто будет запоминать все данные, введенные пользователем.

Этот абзац пропадет после того, как вы введете имя и отправите данные, нажав на кнопку.

Читайте также:  Установка птф гранта ксенон

Теперь осталось в HTML вставить нужные переменные.

источник

Cookies

PHP прозрачно поддерживает HTTP cookies. Cookies — это механизм хранения данных браузером удаленной машины для отслеживания или идентификации возвращающихся посетителей. Вы можете установить cookies при помощи функций setcookie() или setrawcookie() . Cookies являются частью HTTP -заголовка, поэтому setcookie() должна вызываться до любого вывода данных в браузер. Это то же самое ограничение, которое имеет функция header() . Вы можете использовать функции буферизации вывода, чтобы задержать вывод результатов работы скрипта до того момента, когда будет известно, понадобится ли установка cookies или других заголовков.

Любые cookies, отправленные серверу браузером клиента, будут автоматически включены в суперглобальный массив $_COOKIE , если директива variables_order содержит букву «C». Для назначения нескольких значений одной cookie, просто добавьте [] к её имени.

В старых версиях PHP (5.3 или ранее) опция register_globals могла быть включена, что могло приводить к нежелательным и небезопасным операциям. Если эта опция включена, cookies будут представлены как глобальные переменные.

Дополнительная информация, в том числе и особенности реализации браузеров, приведена в описании функций setcookie() и setrawcookie() .

User Contributed Notes 8 notes

[Editor’s note: Wilson’s comment has been deleted since it didn’t contain much useful information, but this note is preserved although its reference is lost]

Just a general comment on Wilton’s code snippet: It’s generally considered very bad practice to store usernames and/or passwords in cookies, whether or not they’re obsfucated. Many spyware programs make a point of stealing cookie contents.

A much better solution would be to either use the PHP built in session handler or create something similar using your own cookie-based session ID. This session ID could be tied to the source IP address or can be timed out as required but since the ID can be expired separately from the authentication criteria the authentication itself is not compromised.

unset( $_COOKIE [ «cookie» ]);
?>

Apenas apaga um índice de uma variável, os cookies ainda vão existir e continuar a ser enviados do servidor pro cliente e vice-versa.
Assim como isso:

[ «cookie» ] = «foo bar» ;
?>

Não cria ou altera o valor do cookie, apenas durante a execução atual, o valor que será passado do servidor pro cliente e vice-versa será o original

Para excluir ou alterar deve SEMPRE sobre escrever o valor antigo com setcookie(), setrawcookie() ou header(), sendo este último não muito comum e dificilmente terá um uso justificável

In response to the solution posted in the comment below, there are some practical issues with this solution that must be kept in mind and handled by your code. I developed an application using a similar «use-it-once» key to manage sessions and it worked great but we got some complaints about legitimate users getting logged out without reasons. Turns out the problem was not tentative highjacking, it was either:

A- Users double click on links or make 2 clicks very fast. The same key is sent for the 2 clicks because the new key from the first click didn’t get to the browser on time for the second one but the session on the server did trash the key for the new one. Thus, the second click causes a termination of the session. (install the LiveHttpHeaders extension on firefox and look at the headers sent when you click twice very fast, you’ll see the same cookie sent on both and the new cookie getting back from the server too late).

B- For any given reason, the server experiences a slow down and the response with the new key (which has replaced the old one on the server) is not returned to the browser fast enough. The user gets tired of waiting and clicks somewhere else. He gets logged out because this second click send the old key which won’t match the one you have on your server.

Our solution was to set up a grace period where the old key was still valid (the current key and the previous key were both kept at all times, we used 15 seconds as a grace period where the old key could still be used). This has the drawback of increasing the window of time for a person to highjack the session but if you tie the validity of the old key to an IP address and/or user agent string, you still get pretty good session security with very very few undesired session termination.

I found a solution for protecting session ID without tying them to client’s IP. Each session ID gives access for only ONE querry. On the next querry, another session ID is generated and stored. If somebody hacks the cookie (or the session ID), the first one of the user and the pirate that will use the cookie will get the second disconnected, because the session ID has been used.

If the user gets disconnected, he will reconnect : as my policy is not to have more than one session ID for each user (sessions entries have a UNIQUE key on the collomn in which is stored user login), every entries for that user gets wiped, a new session ID is generated and stored on users dirve : the pirate gets disconnected. This lets the pirate usually just a few seconds to act. The slower visitors are browsing, the longer is the time pirates get for hacking. Also, if users forget to explicitly end their sessions . some of my users set timeout longer than 20 minutes !

Читайте также:  Установка ксенона в фары лансер 9

IMPORTANT NOTE : This disables the ability of using the back button if you send the session ID via POST or GET.

In response to the solution posted in the comment below, there are some practical issues with this solution that must be kept in mind and handled by your code. I developed an application using a similar «use-it-once» key to manage sessions and it worked great but we got some complaints about legitimate users getting logged out without reasons. Turns out the problem was not tentative highjacking, it was either:

A- Users double click on links or make 2 clicks very fast. The same key is sent for the 2 clicks because the new key from the first click didn’t get to the browser on time for the second one but the session on the server did trash the key for the new one. Thus, the second click causes a termination of the session. (install the LiveHttpHeaders extension on firefox and look at the headers sent when you click twice very fast, you’ll see the same cookie sent on both and the new cookie getting back from the server too late).

B- For any given reason, the server experiences a slow down and the response with the new key (which has replaced the old one on the server) is not returned to the browser fast enough. The user gets tired of waiting and clicks somewhere else. He gets logged out because this second click send the old key which won’t match the one you have on your server.

Our solution was to set up a grace period where the old key was still valid (the current key and the previous key were both kept at all times, we used 15 seconds as a grace period where the old key could still be used). This has the drawback of increasing the window of time for a person to highjack the session but if you tie the validity of the old key to an IP address and/or user agent string, you still get pretty good session security with very very few undesired session termination.

If you want a secured session not tied to the client IP you can use the valid-for-one-query method below, but to safeguard against a scenario where the legitimate user clicks twice, you can use a shutdown function (register_shutdown_function)*.

It will check to see if the script terminated prematurely (connection_aborted), and reset the valid session ID. That way, it’s still valid when the user makes the second request. If the script ends properly, the new session ID will be used instead.

Now, since you can’t set a cookie from the shutdown function (after output has been sent), the cookie should contain both the previous valid session ID and the new one. Then the server script will determine (on the next request) which one to use.

:: Pseudo example:
::
:: [Start of script:]::
:: 1. Get the session ID(s) from cookie
:: 2. If one of the session ID’s is still valid (that is, if there’s a storage associated with it — in DB, file or whatever)
:: ____2.1. Open the session
:: 3. Generate a new session ID
:: 4. Save the new session ID with the one just used in cookie
:: 5. Register shutdown function
::
:: [End of script (shutdown function):]::
:: 1. If script ended prematurely
:: ____1.1. Save session data using the old Session ID
:: 2. Else
:: ____2.1. Save session data using the new Session ID
:: ____2.2. Make sure the old session ID is added to a list of ID’s (used for the purpose described below)
:: ____2.3. Trash the old session storage

There’s still the possibility of some deviant network sniffer catching the session cookie as it’s sent to the client, and using it before the client gets the chance to. Thus, successfully hijacking the session.

If an old session ID is used, we must assume the session has been hijacked. Then the client could be asked to input his/her password before data is sent back. Now, since we have to assume that only the legitimate user has the password we won’t send back any data until a password is sent from one request.

And finally, (as a sidenote) we could obscure the login details (if the client has support for javascript) by catching the form as it is sent, take the current timestamp and add it to the form in a dynamically generated hidden form object, replace the password field with a new password that is the MD5 (or similar) of the timestamp and the real password. On the serverside, the script will take the timestamp, look at the user’s real password and make the proper MD5. If they match, good, if not, got him! (This will of course only work when we have a user with a session that’s previously logged in, since we know what password (s)he’s supposed to have.) If the user credentials are saved as md5(username+password), simply ask for both the username and password, md5 them and then md5 the timestamp and the user cred.

* You could use session_set_save_handler and make sure the session ID is generated in the open function. I haven’t done that so I can’t make any comments on it yet.

источник