Команда разработчиков

public static function start()

{

    if (session_status() === PHP_SESSION_ACTIVE) {

        session_start();

    }

}

А такой код вообще должен работать? При учёте что я после логина перенаправляю пользователя через header "location"?

Потому что у меня - не работает. И если я правильно понимаю логику - работать и не должно. Ведь получается что сначала идёт проверка - была ли запущена сессия, и если да вызывается session_start() и запускается сессия...как то оно не так звучит. Естественно если вызывать его после перехода на другую страницу по редиректу оно всегда будет отдавать false.

Возможно не лучший вариант, но у меня работает в таком виде:

public static function start()

{

        if (isset($_COOKIE{session_name()})) {

            session_start();

        }

}

{} - поставил, чтобы без автозамены было.

---------- Добавлено 15.03.2020 в 22:14 ----------

У меня пока всего 2 контроллера и я просто в нужных методах делал вызов функции проверки аутентификации. Если прав нет - никаких ресурсов -> исключение и 404 статус страницы.

Но вообще да, понимаю что решение кривоватое, в следующей итерации - переделаю.

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

В чем логика проверки имени сессии в кукисах, что бы по его наличию запустить сессию ?

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

Учебная задача, в чём проблема то?) И да, подскажите, какой нормальной функцией php воспользоваться, чтобы запустить сессию только для пользователей, которые уже стартовали сессию на другой странице сайта.

Сессии php в принципе плохая идея использовать.

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

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

Да, предполагал.. Так-то можно вообще всё в куках хранить, но в качестве одного аргументов упоминалось:

Задачи бизнеса. Пользователю дают возможность частично попробовать функциональность сервиса.. без необходимости регистрации.. Когда "подсядет", поймёт плюсы (синхронизация на разных устройствах, длительность, хранение истории и тд)

Видимо, с целью оптимизации? Удвоение количества запросов для покупателей, но кэшированный "статический" контент основной страницы?..

Речь идет о том, чтобы саму куку создавать на клиенте. Технически, её назначает не бекенд, а значит nginx все так же сможет закешировать такой ответ.

В таком случае да, вариантов не особо много.

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

Я вообще делал такую штуку: приходил запрос, на генерацию ответа отведено 10 мс., если за 10 мс. бекенд не успел сгенерировать ответ, он отвечал статусом 202 Acepted, в теле ответа отдавал ссылку, по которой будет доступен ответ, и время, через которое за данными нужно прийти. А на фронте просто крутился лоадер.

А какие варианты вы знаете? Есть два способа: сессии и какой-нибудь JWT.

JWT хорош тем, что клиент присылает тебе все нужные данные сразу, т.е. там хранится пользователь (id, login), и вся нужная инфа, чтобы не ходить в другой источник данных для получения этой инфы. При этом ты можешь верить этим данным, а пользователь может их читать (если сервер этого захочет). Но минусы, это то, что ты не можешь делать токен rewoke, тогда придеться делать какой-то шареный стейт, куда писать все токены, которым больше нельзя доверять. Тогда смысл всей идеи теряется. На своих проектах давно юзаю JWT, так как мне лень вообще пилить сессии собственноручно, ну и под формат SPA больше подходит, т.к. обычно фронт должен отрисовать инфу про юзера, которую он может получить один раз из JWT.

А те минусы что вы описали, про мемкешед, базу, файлы, это все не проблема сессий, а проблемы хранилища.

Ну вы же где то идентификатор авторизации храните. Вот и стартуйте сессию только по наличию этого ключа.

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

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

Мы не против сессий же как таковых.

Речь о том, что это проблемы реализации сессий на пхп, не сессий как таковых, не хранилища, а конкретной реализации.

Что сессиям нужно - механизм как в БД типа lock table, что бы можно было этим управлять.

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

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

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

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

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

edogs, ну это критическая секция, их обычно защищают блокировками, чтобы не ловить баги. Для более тонкого контроля есть session_write_close, есть read_and_close в опциях у session_start.

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

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

Все же считаем, что корни проблемы в реализации, остальное (правильное использование и т.д.) следствие.

Ведь что реализовано?

Вариант 1. Сессии на файлах. Блокировка полная, без вариантов, параллельные потоки ждут.

Вариант 2. Сессии не на файлах. Блокировки нет вообще, конкуретность, результат не предсказуем.

Оба варианта так себе, но вишенка на торте появляется тогда, когда Вы не контроллируете окружение.

Файлы или мемкэшед может быть выставлено как угодно.

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

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

Особенно если вспомнить, что тут же рядом на этом же сайте может быть 3rd party скрипт, который использует эти же функции, но со своими идеями о том, как оно должно работать. Не лучше уж изолироваться тогда?

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