@jonikster

Здравствуйте.
Изучаю PHP. Когда столкнулся с куками и сессиями, возник вопрос:
В каких ситуациях использовать куки?
Когда мы делаем регистрацию и авторизацию, элементарно когда мы ходим по страницам, session_start обеспечивает работу сайта на нашем профиле.
Когда следует использовать куки и сессии, и что с этим в авторизации?
Слышал, что можно использовать при авторизации куки, писать туда логин и хешированный пароль.
Что скажете?
Заранее благодарен!

0

@Phantom-84

Например, во всех.

Можно, но не нужно.

Используйте нормальные источники, в которых не советуют хранить в куках хеш пароля.

0

@jonikster

Phantom-84, тот хеш, который односторонний.
Например для этого есть функции password_hash и password_verify
И если не хранить, то как и для чего тогда использовать куки.

0

@Phantom-84

Все равно. Про "односторонность" этого хеша можно много говорить, но тема не об этом.

Хранить не кеш пароля, а то, что положено?

Добавлено через 1 минуту
Вместо логина также допустимо хранить id пользователя, но, конечно, не во всех случаях.

0

@jonikster

Phantom-84, А что положено? Если без пароля, так куки можно и подделать, тупо взять и вписать логин или ID.

0

@Phantom-84

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

0

@Htext

Сессии пригождаются, когда Вы запускаете серверную программу для конкретного пользователя и дальнейшие ее запуски должны происходить с его индивидуальными параметрами. Например, пользователь делает покупку в магазине, ставит галочки и т.п. Т.е. задает параметры. Их можно хранить в куки. Для каждого пользователя запускается своя сессия (а в файле сессий - там свои параметры для каждого пользователя). Это удобно, т.к. сервер может различать пользователей.
Грубо говоря, куки (а также сессии браузера, что похоже)представляют собой аналог сессий сервера.
Ну, почему. Можно и хеш пароля хранить. В e-mail это, вроде как, и используется.

Добавлено через 1 минуту
Когда куки очищаются - приходится пароль и логин в почту вводить вновь.

0

@Phantom-84

Htext, о какой почте вы говорите?

Что вы хотели этим сказать? Что так не должно быть что ли?

0

Сынок

и сразу пример сюда как Вы это делаете

0

@Phantom-84

Сынок, автор, видимо, неправильно меня понял, думая, что я ему предлагаю хранить в куках только id.

Кстати, с повсеместным переходом на HTTPS в этом тоже есть смысл, если вы не хотите идти на поводу у "власть имущих" и продолжаете использовать на сайте в качестве основного HTTP.

0

@jonikster

Htext, Примерно понял. Но как использовать в связке куки и сессии?

0

@Htext

Когда браузер делает запрос на страницу, из куки передается на сервер соответствующая переменная и ее значение (т.е. то, что было записано в куках). Например, при предыдущем запросе сервер выполнил команду Это означает, что в браузер будет отправлена куки с именем name и значением value.
Т.е. при СЛЕДУЮЩЕМ запросе браузера той же самой страницы на сервер передастся это значение куки.
РНР, после запуска, принимает это значение и записывает его в глобальный ассоциативный массив $_COOKIE[]. В данном случае, в этом массиве появится элемент $_COOKIE['name'], значение которого будет равно value. Причем, заботиться о кодировании/декодировании (если Вы передаете не латинские и не цифровые текстовые значения), не нужно, РНР делает это автоматически (в чем его выгода, например, от программ на С/С++).
Т.о., после запуска программы, которая обрабатывает запрос браузера, имеющий указанную куки, появляется элемент массива. к которому можно будет обратиться, например, так:
Хотя, для корректности, вначале надо бы проверить, содержится ли в этом массиве именно такой элемент, при помощи функции isset(). Если проверки не будет, вот тогда-то и возникает легкая возможность подделки куки, например, путем отправки аналогичного GET-запроса. Впрочем, куки ЛЕГКО можно подделать и так, например, при помощи внедрения на страницу нужного JS-кода, который запишет нужную куки вместо той, что прислал сервер. Например, при помощи букмарклета (я сам пользуюсь таким приемом, чтобы полностью стереть ВСЕ куки на любой странице, в требующихся случаях; или чтобы удалить весь JS с вебстраницы, если ее разработчики перестарались, так сказать; при этом оформление страницы, ее контент и т.п. - не меняются, но никаких запросов она более никуда послать не в состоянии... но, речь не о том).

Т.о., после выполнения команды у нас получится, что значение переменной $x будет равно value.
Что касается сессий сервера (не путайте с сессиями браузера). Перед тем, как читать куки, сервер должен открыть сессию, например, функцией session_start(). После того, как будет открыта сессия сервера, можно присвоить значение переменной $x - см. выше. И сервер должен сравнить - ТО ЛИ САМОЕ значение куки получено от браузера, совпадает ли это значение с тем, которое было ранее (на предыдущем этапе, при отсылке куки браузеру) запасено в сессии сервера, т.е. в глобальном массиве $_SESSION[]? Если да, то сервер "понимает", что он работает с запросом именно от того самого пользователя. И дальше можем делать все необходимое. А если полученное значение куки браузера (записанное в переменную $x) и запасенная куки сервера не совпадают - стало быть, это не тот пользователь. Здесь можно или вывести ошибку, или как-то иначе обработать запрос браузера. Имея в виду, что пользователь не авторизован.

Добавлено через 13 минут
Это необязательно делать, РНР сам автоматически хранит id. Если даже куки будут отключены в браузере, тогда id будет добавляться в GET-запросы.

1

@Phantom-84

Htext, в данном случае я имел в виду id пользователя, а не сессии. Читайте предысторию.

Добавлено через 1 минуту
Не будут. Вы сами должны его добавлять.

Добавлено через 6 минут
...Если считаете это хорошей идеей

0

@jonikster

Htext, благодарю вас за потраченное время. Хороший ответ, который пролил свет на многие вещи. Теперь мануалы в зубы, и решать задача, тогда придёт и остальное))
Ещё раз, огромное спасибо.

0

@Htext

??... Вообще, Д. Котеров, А. Костарев (книга: РНР5, 2016 г.) считают иначе, цитата:
"Самый распространенный пример использования cookies - имя входа и пароль пользователя, использующего некоторые защищенные ресурсы Вашего сайта. Эти данные, конечно же, между открытиями страниц хранятся в куки, для того, чтобы пользователю каждый раз не пришлось их набирать вручную".

Будут. Чтобы окончательно в этом убедиться, читаем цитату из книги (стр.516):
"...запустите сценарий 29.3. предварительно отключив cookies..., а затем наведите мышь на гиперссылку и посмотрите в строке состояния, какой адрес имеет ссылка...
Вот адреса этих ссылок с точки зрения браузера...:
http://example.com/smt.php?par... SSID=86a20..."
Пример ссылки я немного сократил, чтобы показать главное: при отключении куки РНР, в самом деле, АВТОМАТИЧЕСКИ(!) добавляет к ссылкам идентификатор сессии (уникальный для каждого пользователя). Идентификатор всегда добавляется в конец ссылки.
Более того, цитата (с.516-517):
"РНР умеет не только изменять гиперссылки, но и также добавляет скрытые поля в формы, которые формирует сценарий, чтобы передать идентификатор сессии... Это ставит последнюю точку над i в вопросе поддержки пользователей, которые отключили у себя cookies".
Дальше на странице приведен рабочий пример, когда при отключении куки РНР сам, автоматически добавляет дополнительное скрытое поле с идентификатором сессии (name, value).

Я слегка сократил цитаты, т.к. книга у меня - в печатном варианте, набирал вручную. Но, смысл - передал.
Итог такой. Мы, конечно, при отключенных куки в браузере, можем и самостоятельно (если хочется) добавить PHPSESSID к ссылкам (или добавить еще одно поле в форму - в случае POST-запроса). Но, если этого не сделать, РНР сделает это автоматически. Ибо это, все же, РНР, а не С/С++. Такими вот нюансами он и удобен. При том, что работает всего лишь раз в 2...5 медленнее, чем аналогичная программа на С. Если, конечно, написать правильно. Я проверял при работе с файлом около 4 МБ.

0

@Phantom-84

Значит, это плохой источник. Если даже книга для начинающих, там должен был быть информационный блок, поясняющий, что так делать не нужно.

Лучше проверьте на практике. Или мы с авторами по-разному понимаем слово "автоматически", или кто-то из нас врет

Добавлено через 4 минуты
Это последний гвоздь в гроб их безопасности. Так было бы точнее.

0

@Jewbacabra

Htext, каким образом php узнает что куки отключены в браузере?

0

@Phantom-84

Наверное, Htext писал про это:
Чтобы увидеть эффект, отключение кук, видимо, нужно выполнять аналогичными директивами на стороне сервера. Это какой-то анахронизм, к тому же крайне небезопасный. В настоящее время, когда повсеместно используется JS, "обработчик вывода" не сможет "отловить" все, что положено. Хотя в "семерке" все же пытаются как-то с этим справиться:
Добавлено через 2 минуты
Видимо, разработчикам больше нечем заняться

0

@Htext

Элементарно. Например, после того, как определит, что куки вообще не содержатся в запросе, несмотря на попытку сервера их установить. Хотя, как это определяется фактически, мне неизвестно, я не вникал в работе интерпретатора РНР на низком уровне.
Безопасность здесь вообще ни причем.

Добавлено через 2 минуты
Точное название опции уже не помню (но, синтакис похож), естественно, она должна быть включена для указанной возможности.

0

@Jewbacabra

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

Это был намек, а не вопрос, ну да ладно. На первом использовании session_start php использует оба механизма передачи sid: через заголовок set-cookie и добавляя ко всем ссылкам на странице. И получится что из-за 1.5 чудаков, которые выключили куки пришлось пожертвовать безопасностью всех остальных нормальных пользователей. И использование js доставит массу неудобств, т.к. php просто не сможет распознать все ситуации куда надо добавить sid

0