Зачем используют сессии?

Достаточно долгое время занимаюсь веб технологиями и PHP и до сих пор не могу понять зачем (не как, а зачем) используют сессии.

Опишу механизм сессии упрощенно
При сессии пользователю ставится cookie с идентификатором сессии (для PHP - PHPSESSID).
Вся информация пользователя, которую надо сохранить, сохраняется в файлах на сервере.
И при обращении пользователя, сервер читает идентификатор (PHPSESSID) и ищет файлы ассоциированные с этим идентификатором.
Фактически сессия - это куки на сервере.

Механизм кук более простой.
Вся информация пользователя, которую надо сохранить, сохраняется в файлах на компьютере пользователя (в файлах, называемых cookie). И оттуда же читается.

В чем проблема
Проблема в том, что срок жизни сессии устанавливается на сервере.
В связи с этим возникает множество неудобств
1) По умолчанию он 24 минуты.
2) Не всегда есть доступ к php.ini. (Обычный хостинг)
3) Максимальный срок жизни сессии 24 часа.

Моя задача, как программиста сделать использование сайта максимально удобным. Да и как пользователь я хочу чтобы мне было комфортно работать в интернете.

Часто возникает ситуация, что я авторизовавшись работаю с сайтом. И после закрытия браузера (или через определенное время) моя авторизация пропадает.
Нужно вводить данные снова. Это не удобно.
С куками, таких проблем, разумеется нет.

Зачем используют сессии, когда есть куки? Куки удобнее, проще, универсальнее.
Не будет "автовыхода" с сайта. Человек сам решит когда ему выйти. Не нужно настраивать сервер. Данные каждого человека хранятся на его компьютере (в его куках). Сплошные преимущества.

0

useruser, Основное и принципиальное отличие в том, что куки хранятся в браузере, что не очень безопасно, а сессия на сервере.
Токен авторизации можно хранить как в сессии, так и в куках. Определяется галочкой "запомнить меня" при входе.

0

useruser,

3) 2) Не всегда есть доступ к php.ini.

0

Большой массив данных в куку вы не сможете сохранить.

0

Сообщение от sad67man Основное и принципиальное отличие в том, что куки хранятся в браузере

На компьютере пользователя (для каждого браузера хранение организовано немного по разному). Особых проблем с безопасностью не вижу.
Что взять куки с компьютера, что взять куку PHPSESSID и получить все данные с сервера.
Не принципиально, особенно с учетом того что в куках обычно нет ничего интересного. Они "ключ" к данным. И этот ключ всегда на компьютере пользователя. А иначе он бы просто не получил доступ к своим данным на сервере.

Сообщение от sad67man Токен авторизации можно хранить как в сессии, так и в куках.

Токен авторизации, как я знаю, может быть только в куках.
В куке PHPSESSID (или другое название при правке php.ini)- если реализуется механизм сессий.
В адресной строке (GET запрос www.somesite.ru&PHPSESSID=SecretPass). Такое уже редко встретишь
В любой сторонней куке, при реализации своего механизма авторизации (отказ от сессий, делаем на куке).

Преимуществ сессий пока не вижу.

Сообщение от HotReboot ini_set('session.gc_maxlifetime', $time);

Да так можно. Но не всегда. Тут всё решает хостер.
Например, вы можете попробовать ini_set max_execution_time=0, но через 2 минуты ваш скрипт остановится.
(На стаке есть тема.) Хостеры ограничивают некоторые параметры.
Можно и через .htaccess - но если веб сервер будет Nginx, то разумеется это не сработает и наверно надо будет искать ещё решения.
Так зачем всё это, когда есть куки? Куки - и вы не зависите от параметров сервера.

Сообщение от sash23 Большой массив данных в куку вы не сможете сохранить.

Для этого есть база данных. Кука - ключ к данным, токен авторизации, файл хранящий "минимальные" настройки.

0

В 2к20 году юзать что то одно - это от лукавого. Сессия для сервера, куки для клиента. Тут нечего пояснять больше - основа веба.

Добавлено через 2 минуты
Учите матчасть

Добавлено через 4 минуты
Веб-хостинг это прошлый век. Сейчас вдс/впс сервер недорого стоит и доступны. На счёт хостеров - демагогия бессмысленная и ненужная

0

useruser,

Сообщение от useruser Цитата Сообщение от HotReboot Посмотреть сообщение ini_set('session.gc_maxlifetime', $time); Да так можно. Но не всегда. Тут всё решает хостер.

Достаточно изменить место хранение, что бы хостер не тёр tmp
Кстати и гонять служебный трафик между клиентом и сервером так же не есть хорошо. Особенно во времена повального интернета на смартфонах.

0

Сообщение от Fart83 Сессия для сервера, куки для клиента.

Вы вообще о чем? Я даже кратко описал механизм работы. Если я что то не правильно описал - поправьте.

Сообщение от Fart83 Учите матчасть

Разберитесь пожалуйста сами. Я считаю, что хорошо разбираюсь в этом вопросе.
Поэтому я и не спрашиваю как, а спрашиваю - зачем?

Сообщение от Fart83 Веб-хостинг это прошлый век.

Это к хостерам, коих сейчас +100500. И все они предоставляют шаред хостинг.

Сообщение от HotReboot Достаточно изменить место хранение, что бы хостер не тёр tmp

Можно. Но зачем? Зачем лишний код, настройка сервера. Да и хостер может запретить что угодно.
Да, такое редко - но зачем об этом думать? Какие преимущества у сессий?

0

Сообщение от useruser Зачем используют сессии, когда есть куки?

Вопрос не совсем корректный, потому что такие понятия как "сессия" или "куки" находятся на разных уровнях. Сессия - абстракция в основе которой лежат куки. И то что в php называется механизмом сессий - просто конкретная реализация этой абстракции. Соответственно если для некоторой задачи стандартный механизм подходит - то почему бы им не воспользоваться, если нет то можно свой, явно используя для этой цели куки.
Нужно только понимать, что куки приходят от клиента, и доверять им нельзя, и например в них нельзя хранить такие данные как id пользователя и т.д, а какой-ниюудь трудноподбираемый токен - нормально

0

useruser,

Сообщение от useruser Цитата Сообщение от HotReboot Посмотреть сообщение Достаточно изменить место хранение, что бы хостер не тёр tmp Можно. Но зачем? Зачем лишний код, настройка сервера. Да и хостер может запретить что угодно.

Вам уже объяснили какие. Если вы сразу не поняли, то уже и не поймёте. А куки так же пользователь может запретить у себя.
P.S. И да - у себя в профиле уберите "безопасность". Хранить данные пользователя в куках есть абсолютное ламерство.

0

Сообщение от useruser до сих пор не могу понять зачем (не как, а зачем) используют сессии

Обычный кеш на файлах с решенными проблемами синхронизации и т.п. Если вам это не нужно, не используйте. Есть еще более быстрые способы кеширования (что у нас работает быстрее, чем диск? ), которые можно использовать через тот же механизм сессий или минуя его.

0

Сообщение от Jewbacabra И то что в php называется механизмом сессий - просто конкретная реализация этой абстракции.

Я так и описал. Всё верно.
Я показал 2 механизма и говорю - смотрите с сессиями могут быть проблемы. Основная причина - срок жизни сессии.
Привел аргументы.

И на практике эта проблема есть. Вот прямо сейчас на сайте крупного магазина, где я залогинен, истекла сессия.
И мне снова пришлось авторизироваться.
Вы можете сказать - надо выполнить настройку сервера. Возможно. Но такое встречается довольно часто. Сессия истекает, вас разлогинивает. Так уж сложилось.

Сообщение от Jewbacabra что куки приходят от клиента, и доверять им нельзя

Любой информации от пользователя доверять нельзя. Для этого и фильтруют данные (обычно регулярными выражениями/плейсхолдерами/форматированием и т.д. по крайней мере я так делаю).

На практике я не вижу преимущества сессии, только недостатки.

0

Сообщение от useruser На практике я не вижу преимущества сессии, только недостатки.

Преимущества перед чем?

Сообщение от useruser Любой информации от пользователя доверять нельзя. Для этого и фильтруют данные

Я не про это. Например, пришло в куках user_id=10. Такую куку подобрать не составит большого труда, и никакой фильтр не поможет. А если будет что-то такое token=BzKPzTl+R1dFwWjDzGtsX4DX1P/bXkhKHnVaHinl2CBzZkskclv0ErXofF+WAdAQcW7SorjPZIELsJf2lwMbtVK2rP0Wn/jSMkxUjZtrj4qndsWyog88TmrxKrZSiyVi/kNRAF0JqYXcL и так просто уже не подобрать

0

Сообщение от useruser И на практике эта проблема есть. Вот прямо сейчас на сайте крупного магазина, где я залогинен, истекла сессия.

Еще раз - вы можете хранить токен авторизации в куках. А при каждом запросе доставайте по токену текущего пользователя. Для каждого устройства можно генерировать свой уникальный токен. У каждого токена может быть свой срок действия. Получается у вас должна быть отдельная таблица в БД с токенами для авторизации.

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

0

Сообщение от useruser Особых проблем с безопасностью не вижу. Что взять куки с компьютера, что взять куку PHPSESSID и получить все данные с сервера.

Ключ авторизации временный. Его можно в любой момент принудительно сбросить. Кроме того, кешировать можно в том числе и такие данные, которые вы не собираетесь выводить.

0

В дополнение к моему посту выше. Можно еще добавить такой функционал, как "выйти из под всех устройств", удалив из БД все токены авторизации текущего пользователя.

0

Сообщение от Jewbacabra Я не про это. Например, пришло в куках user_id=10.

Ну это совсем начальный уровень.

Сообщение от sad67man Получается у вас должна быть отдельная таблица в БД с токенами для авторизации.

Вы привели пример реализации задачи.
У нас есть 1 пользователь, который входит с разных устройств. При удачной проверке логин/пароль, мы устанавливаем на устройстве куку.
В куке прописан токен. Этот же токен пишем в бд. При любом действии проверяем есть ли токен у пользователя, есть ли такой в бд. Если есть - идентифицируем пользователя.
Реализация задачи на токенах.

А что с сессиями?
Как в данном примере сессия даст преимущество?

Сообщение от estic Ключ авторизации временный.

И что из этого? Сессия истекла - пользователю надо заново залогиниться. Это не удобно.

Можно сказать - что если злоумышленник захватит устройство, то он сможет на нем работать 24 минуты (стандартное время сессии).
В то время как с кукой - постоянно (то что срок жизни он продлит даже не обсуждаем).
Но можно легко реализовать механизм "выйти из под всех устройств". Что часто и делается во многих проектах.
Все эти вопросы безопасности уже давно решены двухэтапной аутентификацией.

0

Сообщение от useruser ожно сказать - что если злоумышленник захватит устройство, то он сможет на нем работать 24 минуты (стандартное время сессии).

Тут еще нужно учитывать, что сессия должна быть открытой. Если не видите смысла - то скорее всего в вашем случае оно и не нужно.

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

0

Сообщение от useruser В куке прописан токен. Этот же токен пишем в бд. При любом действии проверяем есть ли токен у пользователя, есть ли такой в бд. Если есть - идентифицируем пользователя.

Вы описываете сессии, но не встроенные в php (которые на файлах), а реализуемые непосредственно в скриптах и на бд-таблицах.
И похожее на то что только для авторизованых.

PHP-cессии отличаются немного другим подходом.
Например посмотрите в комментариях к странице
https://www.php.net/manual/ru/... andler.php
Есть так-же реализация на db-таблицах.
Стартовать-ли сессии только для авторизовных,
разлогинивать-ли через какое-то время,
что именно держать в сессии ...
можно так-же решить в скриптах.

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

А то что получаете с клиента, может оказаться чем-угодно,
и это однозначно куча лишнего кода, проверять эти данные, фильтровать ...

0

Сообщение от sad67man В дополнение к моему посту выше. Можно еще добавить такой функционал, как "выйти из под всех устройств", удалив из БД все токены авторизации текущего пользователя.

не надо ничего удалять из БД)))
надо при входе на другом устройстве вносить в БД токен ЭТОГО ДРУГОГО устройства, а при проверке совпадения сессионного токена с токеном из БД делать разлогин на устройстве, где он не совпал, оставляя ВСЕГДА только ОДНО залогиненное устройство)))
всё намного проще: в ларавеле видимо целая отдельная таблица для этого создана? )))
нужен один столбец для этого

0