акк уже месяц как грохнули, а юзер ходит по сайту и думает что он залогинен

а "сгенерированное число" где будет хранится? Откуда его брать чтоб сравнивать? Какова разрядность числа?

то есть схема:
php->файл_сессии
очень затратна по ресурсам, по сравнению с:
php->БД->файл_бд
?
В базу нужно лезть в любом случае за актуальными данными, в сессии хранится только user_id. Если так напрягает лишнее обращение к hdd, можно перенести хранилище на tmpfs.

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

В DB, можно ещё привязать IP, но у меня больше 85% трафика с мобилок, у них он динамический.


walerus

8*2, 8

online - больше 40.000

_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.

Если юзер видит свой логин на странице, он считает что авторизован. Ты же хочешь обмануть юзера. Не самое лучшее решение с позиции юзабилити, стоит ли мнимая оптимизация этого?
К тому же если ты решил обманывать пользователя, зачем тогда вообще куки? Смысл в каждом запросе слать ненужную серверу информацию? Если уж так рьяно взялся за оптимизацию, то наверно в курсе что для рендеринга страницы браузер шлёт множество http запросов, в каждом из них будут эти куки с логином. Это же лишний трафик
Пиши тогда логин в local storage и выводи через JS на клиенте, тогда логин можно будет отображать даже на статичном html Ну а что? Какая разница? Всё равно же эта информация не актуальная.

ну я же не просто так спросил, это имеет прямое отношение к безопасности

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

Про этот момент даже не подумал. Что касается user_agent, хотел сделать небольшую защиту от перехвата или подбора идентификатора сессии, маловероятно подобрать значение из 32 байт, но всё же. Согласен что при моей нагрузке ещё можно использовать сессии (только хранить в памяти), но есть же какой то весомый повод использовать куки, как это делают в крупных проектах?

_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.

зная твой алгоритм хеширования, достаточно подобрать

что намного проще, чем брутить пароль. Н а"безопасность через неизвестность" в этом деле особо полагаться нельзя. Но мой вопрос о разрядности числа так и остался без ответа.

Сравнение "куки vs сессии", это как "колёса vs автомобиль"
Куки - это всего лишь заголовки, с их помощью обходиться stateless ограничение http протокола, т.е. можно помечать клиента, и отличать его запросы от других. Сессии же - это механизм уровнем выше. Вопрос не в том использовать сессии или нет, вопрос в том, использовать нативную реализацию этого механизма в PHP, или изобретать свою. По каким причинам не устраивает нативная? Не нравится обращение к ФС? Так я уже выше упоминал, что файлы совсем не обязательно хранить на диске. Нужно использовать другое хранилище? Можно назначить свой обработчик через session_set_save_handler.
У файлового хранилища проблема не в быстродействии, а в блокировках из-за чего будут тормоза при неправильном использовании с множественными ajax запросами, но ты об этом почему то не упоминул, зато борешься с лишним обращением к ФС. На фоне всего остального, что делает твой скрипт, это пшик.

Можно подробнее

_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.

сделай 2 скрипта


в одном сделай

session_start();
sleep(100);
echo 'hello i\'m very long operation'

во втором

session_start();
echo ' hello world'

потом в браузере открой в одной вкладке первый файлик, потом второй =) и смотри сколько времени потребуеться что бы отобразить второй ;)

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

Кто не понял, второй файл встаёт в очередь (пока первая сессия не отработает) и занимает свободные воркеры.

Я же не зря попросил подробнее описать, как пользоваться сессиями при использовании аякса.

_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.