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

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

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

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

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

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

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

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

0

Сообщение от Verolomstvo ну так если не теряют, то зачем им сидеть с нескольких, я не пойму в чём прикол держать в онлайне несколько учёиок, либишь следить сколько и какие у кого устройства? Так пиши в логи новое, если не совпало с имеющимся по учёту

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

Далее 2 варианта
1) автоматически продлевать токен, пока вы активно пользуетесь сайтом - вас не будет выкидывать. А если вы давно не заходили - тогда нужно будет войти.
2) просто когда истекает срок действия заставить войти, генерируя новый токен.
3) совместить 2 варианта.

Если генерировать общий токен для всех устройств, то какие тут могут быть проблемы? Допустим вы сделали токен на 30 дней. Потом в последний день зашли с другого устройства - и получается можете его продлить и для другого устройства тоже. Либо вас выкинет через 5 минут, так как текущий токен закончился. Именно поэтому для каждого отдельного устройства генерируется свой - где у каждого свой срок действия. Когда я захожу с одного устройства - это никак не влияет на токен и его срок действия другого устройства.

Далее можно в БД кроме самого токена еще и записывать само устройство - тогда мы можем сделать так, чтоб если каким-то образом токен удалось украсть, то по нему не могли зайти с другого устройства.

0

Сообщение от sad67man И тут не известно вы ли это вообще, может устройством уже пользуется другой человек.

а то, что на аккаунт залогинено несколько устройств - это не должно нас смущать, ведь на каждом может быть разный пользователь, ломанувший аккаунт

смотрим такую ситуацию: я залогинен с ПК, кто-то залогинился с ТЕЛА, меня на ПК выкидывает

тут либо можно сообщить пользуну, что на аккаунте несколько устройств и предложить ему провериться он ли это либо он будет спокойно сидеть с нескольких устройств и ничего не заметит, что его ломанули либо он залогинится и злоумышленника выкинет и тот опять залогинится и тебя выкинет и ты обратишься в обратку что что-то не так либо тупо сменишь пасс и залогинишься ОДИН

0

Сообщение от Verolomstvo смотрим такую ситуацию: я залогинен с ПК, кто-то залогинился с ТЕЛА, меня на ПК выкидывает

Если пользователь сам сидит на нескольких устройствах - то это будет не удобно.
А так как раз за счет того, что у вас в БД хранятся токены всех устройств - то когда появляется новое устройство - можно оповещать пользователя, что произошел вход/попытка входа с такого-то устройства, в таком-то городе, вам в VK не приходили такие сообщения?
Тогда пользователь сам решит, что делать. Если это был не он, то подстрахуется и поменяет пароль. Нажмет кнопку "выйти из под всех устройств" и т.д.

0

Сообщение от Verolomstvo крутой программист написал метод getProjecDir, который делает

Вам этого не понять. Но смысл в этом есть.

Сообщение от Verolomstvo и везде его суёт getProjecDir() . '/путь', вызывая каждый раз dirname()

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

Сообщение от Verolomstvo chdir(dirname(__DIR__));

Появляется зависимость от рабочего каталога. Программные файлы не должны от этого зависеть.

Не разводите оффтоп. Т.е. на это сообщение лучше не отвечать.

0

Сообщение от estic Программные файлы не должны от этого зависеть.

какие программные файлы?
какая зависимость?
мы каталог сменили и вместо

require dirname(__DIR__) . '/путь';

пишем просто ВЕЗДЕ В ЛЮБОМ МЕСТЕ СКРИПТА

require 'путь';

магия

Сообщение от estic Хотите экономить на мелочах, можете использовать константу, как обычно делаю я. Но популярные фреймворки - это не про экономию.

вот уже теплее, можно было хотя бы константой зафиксировать, а то сто раз dirname(__DIR__) НА! НА! НА! пока ядро собирали инклудами конфигов потом смотрим в регене скрипт полсекунды вместо одной тысячной

суперпрограммист я так думаю потерялся в своём симфони, помешался на ООП и решил что вызов интерпретатора работает как синглтон и можно одну и ту же функцию юзать без затрат, интерпретатор же уже вызвали

ну это всё лирика, но return dirname(__DIR__) в методе getProjectDir() - это было круто

0

Сообщение от Verolomstvo он какие тут ограничения снял? хотел выйти в РУТ проекта? так напиши в точке входа

Точка входа более "подвижная", чем ядро.

0

Сообщение от estic Появляется зависимость от рабочего каталога. Программные файлы не должны от этого зависеть.

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

0

Сообщение от Verolomstvo require dirname(__DIR__) . '/путь'; пишем просто ВЕЗДЕ В ЛЮБОМ МЕСТЕ СКРИПТА

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

0

Сообщение от sad67man И тогда chdir(dirname(__DIR__)); никак на это не влияет.

особенно если невнимательно читать, где мы разместили этот код

Добавлено через 1 минуту

Сообщение от estic Точка входа более "подвижная", чем ядро.

а где мы грузим ядро?

Добавлено через 4 минуты

Сообщение от sad67man И такой способ на самом деле достаточно часто используют, чтоб вместо dirname(dirname(dirname(__DIR__))) - писать путь от корня.

особенно, если не читать документацию и не знать, что у dirname() есть параметр levels

а что тут такого зафигачим dirname(dirname(dirname(__DIR__))) вместо dirname(__DIR__, 3)

0

Verolomstvo, Меня относительные пути больше пугают. Потому что люблю перемещать файлы с классами то в одну папку, то в другую. От этого не должен страдать код.

0

Сообщение от Verolomstvo а где мы грузим ядро?

Сослаться на ядро можете при помощи __DIR__ точки входа, однако "корень проекта" лучше определять через __DIR__ в (одном из) файле ядра. (Конечно, если он есть. Простые ядра для одной точки входа можно прямо в ней разместить. Но как только становится нужна еще одна точка входа, сразу понимаешь, почему за основу отсчета лучше брать файлы ядра.)

Добавлено через 4 минуты

Сообщение от sad67man Меня относительные пути больше пугают.

Он или потроллить нас решил. Или действительно многого не понимает. Предлагаю больше "не вестись" на это. Тема совсем про другое.

0

estic,

мы в папке public, файл index.php
теперь можно В ЛЮБОМ МЕСТЕ вместо require_once dirname(__DIR__) . '/путь' писать require_once 'путь'

если структура

папка
папка
public
vendor

то путь ВЕЗДЕ МОЖНО ПИСАТЬ не require_once dirname(__DIR__) . '/папка', а просто require_once 'папка'

Добавлено через 4 минуты

Сообщение от estic Он или потроллить нас решил.

чтобы не расслаблялись и не писали дичь

0

Verolomstvo, я вам уже один раз про chdir для 'vendor/autoload' и т.п. написал. Оставьте рабочий каталог для обрабатываемых файлов. Если не можете обойтись без относительных путей для программных файлов, используйте include_path (set_include_path). Другие могут.

0

Сообщение от estic Другие могут

оно и видно

0

Сообщение от Verolomstvo оно и видно

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

0

Сообщение от estic Да, я вижу в показанном фрагменте абсолютный путь.

особенно, если забыл, что это код метода СИМФОНИ, и этот метод долбит функцию dirname() при каждом его вызове

но нам этого мало

dirname — Возвращает имя родительского каталога из указанного пути

мы возьмём и ещё раз его вернём

супервозврат

Добавлено через 7 минут
ещё для крутизны можно __DIR__ переопределить

мы же пишем СИМФОНИ

0

Сообщение от useruser множество неудобств

В целом я согласен с Jewbacabra. Механизм сессий может быть какой угодно. Не подходит встроенный в PHP - используйте другой. В том же Laravel есть свои реализации сессий, где данные можно и в БД хранить, и в Redis.

Т.е. описанные вами неудобства относятся только к стандартному механизму сессий. Если эти неудобства для вас критичны - используйте другой механизм.

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

Чтобы хранить информацию, которую не хочется или нельзя хранить в куках.

Например, Laravel может хранить тексты ошибок валидации в сессиях, чтобы они сохранялись после редиректа (юзер заполняет форму с ошибками - ошибки сохраняются в сессию - юзер редиректится на ту же форму методом GET - ошибки берутся из сессии и отображаются).

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

Другой пример - корзина неавторизованного пользователя. Можно, конечно, написать свою реализацию её хранения, но работать это будет по тому же принципу, как работают сессии.

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

Добавлено через 17 минут

Сообщение от Verolomstvo Не должен пользователь сидеть на сайте с нескольких устройств.

Обычно функционал сайта зависит от пожеланий заказчика, а не от необоснованных фобий программиста.

Я как-то здесь дискутировал с кем-то, кто считал, что в никах пользователей не должно быть спецсимволов. Какой-то цифровой фашизм.

Но на своём личном сайте, безусловно, вы можете делать что угодно.

0

Сообщение от Jodah Другой пример - корзина неавторизованного пользователя. Можно, конечно, написать свою реализацию её хранения, но работать это будет по тому же принципу, как работают сессии.

И это ещё один минус сессий.
На практике корзина неавторизованного пользователя реализуется через сессии. Пользователь может добавить товар в корзину, пойти на другой сайт и сравнить цены, решить что покупать тут ему не надо. А потом передумать и вернуться - а сессия уже истекла и в корзине пусто. Реальный пример из жизни. И это раздражает.

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

Сообщение от Jodah Или когда юзер заполняет форму (Имя, Логин и т.п.), затем уходит со страницы с формой и через какое-то время возвращается, можно взять из сессии введённые им ранее данные

Никогда не видел такого. Если не ошибаюсь, это реализуется через $POST (просто подставляем оттуда, если там что было).

0

Сообщение от useruser И это ещё один минус сессий.

у сессии нет минусов. Эта технология либо решает вашу проблему либо нет. Это тоже самое что сказать: "У вэб-сокетов есть один существенный минус - они не снижают ставку по ипотеке! Зачем их вообще придумали?"

1

Сообщение от useruser это реализуется через $POST

это на один заход, если просто обновить потом страницу с формой, то сброс будет

Добавлено через 4 минуты
useruser, у сессии есть такой вот плюс: если курлом бот долбит страницу, на которой есть session_start() и ТУПО стоит проверка SID при отправке запроса, то курл не сможет её заспамить, то есть отправить запрос на возврат заголовков, взять оттуда SID и отправить с этим SID запрос не получится, так как при каждом curl_exec на той стороне будет новый SID для курла

0