Класс для работы с сессиями

Просто надо пользоваться ванильными сборками php, а не пакетами, написанными людьми с дебианом головного мозга.
Свой пакет можно собрать да хоть бы через checkinstall.
В ext/session вряд ли чего-то можно наворотить, кроме полного переписывания - там, мягко говоря, легаси-код, в который лезть все боятся =)
 
fixxxer а чего тебе вообще с кроном не нравится? Выглядит разумно как бы, отдельный процесс на сбор мусора. Правильнее, чем давать нестабильное время работы скрипта только потому, что он решил пойти мусор собирать.
 
А что вы там храните 3 месяца? Если вам нужно долго хранить данные - это в базу. Вот по-этому и не люблю сессии - на их основе чего только не делают, и большая часть - совершенно не по делу, начиная от долгосрочных хранилищ и заканчивая кешированием "что бы базу не грузить".
Я ничего не храню. Это накопилось столько за 3 месяца работы сайта, если не чистить папку с сессиями.
Переименовал папку с сессиями и теперь find /var/www/sitename.ru/tmp_old/ -type f -print0 | xargs -0 rm
 
fixxxer а чего тебе вообще с кроном не нравится? Выглядит разумно как бы, отдельный процесс на сбор мусора. Правильнее, чем давать нестабильное время работы скрипта только потому, что он решил пойти мусор собирать.
Мне не нравится конкретно дебиановская реализация:
1) ей пофигу на то, что session.save_path может быть переопределен в любом месте (
2) нигде про это не написано большими красными буквами
3) аргументация такого решения - псевдобезопасность
все бы было хорошо, если бы это включалось отдельно какой-то командой.

время работы, кстати, вполне стабильное, если session gc вызывать после шатдауна скрипта (вот тут не уверен, как именно оно сейчас реализовано)
 
MiksIr
Т.е. ты и в Yii не используешь сессию?и куда ты деваешь данные пользователя, в кеш, да ну?
 
MiksIr
Т.е. ты и в Yii не используешь сессию?и куда ты деваешь данные пользователя, в кеш, да ну?
Какие такие "данные пользователя"? Все данные пользователя хранятся в таблице пользователей в соотвествующей строчке, а если их очень много в разных связанных таблицах и эта выборка узкое место - то конечно в кеш, кудаже еще.
 
MiksIr
Я про классические ситуации когда тебе на странице надо выводить например какие-то данные пользователя(допустим тут кешировать блоки нельзя). Твоя фраза "я не использую сессии" слишком броско звучит как-то.
 
В ext/session вряд ли чего-то можно наворотить, кроме полного переписывания - там, мягко говоря, легаси-код, в который лезть все боятся =)
Так переписали же, не? Он же теперь вроде тру-объектные хэндлеры умеет?
 
флоппик
Нет, погоди я же не про один user_id, а например name, status, etc... параметры за которыми лень каждый раз в базу лазить, ну и в кеш их не кинешь если у тебя куча пользователей, памяти не хватит(немного преувеличиваю).
 
В базу не лень лазить, в базу я все-равно лезу для проверки пользователся - есть ли он, не изменился ли его пароль. Считаю это обязательным, иначе в случаях каких-то изменений по пользователю со стороны администратора (вплоть до удаления) в случае хранения всего в сессии пользователь об этом и не знает до следующей аутентификации.

Хотя для определения - авторизован пользователь или нет, вообще в базу лазить не обязательно, достаточно ставить ему криптованную куку после авторизации. Так что если не хотите лазить в базу, то банальное $_SESSION['is_logged_in'] меняется на проверку куки.

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

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

Сессии хороши для начинающих. Для простых каких-то скриптиков. В некоторых отдельных случаях для кого-то...например, корзина посетителя, хотя, опять же, я кладу корзину в базу даже для неавторизованных - это дает больший простор для анализа.
 
MiksIr
А если Уася залез в локал сторедж?А в куки ты пихаешь токен какой-то значит?
 
MiksIr
А если Уася залез в локал сторедж?А в куки ты пихаешь токен какой-то значит?
Конечно. Хеш от юзерагента, IP (если нужна привязка к IP), время (если нужно ограничить сессию по времени) и секретный токен приложения - как минимум.
Так как я лезу все-равно в базу - то подмешиваю еще хеш пароля пользователя - это и дополнительная защита если токен приложения утечет, и полезная плюшка сброса всех сессий пользователя при смене им пароля (старые токены просто станут невалидны).
А если юзер залезет и поменяет там свое имя... ну будет хвастаца друзьям, не более - оно же только для отображения у него же в браузере, не более.
 
MiksIr
нефигово ты так токен подмешиваешь, чего там только нет :) Айдишник на время реквеста приложения в тот же запрос из базы тащишь по токену?
 
Ну кстати встроенная авторизация Yii приблизительно так и работает. После аутентификации они сажают куку с данными пользователя и проверочный хеш по этим данным + токен приложения. Т.е. далее все работает без базы. И не дай бог protected/runtime/state.bin окажется доступным по http и его можно будет скачать... а там как раз токен приложения.
 
MiksIrнефигово ты так токен подмешиваешь, чего там только нет :) Айдишник на время реквеста приложения в тот же запрос из базы тащишь по токену?
Ну, я обычно примерно то же самое в токен подмешиваю. На самом деле, поразмыслив, понял что я на самом деле сам уже сам давно ничего в сессии не храню, кроме разве что каких нибудь сортировок/фильтров в админке :)
 
MiksIr
Я встроенным не пользуюсь, он мне не нравится( Не все без базы, правила проверяются в ней))
 
> кроме разве что каких нибудь сортировок/фильтров в админке
Ну которые тоже в куку можно перенести или для экономии трафика - в локал сторадж =)
 
MiksIr
Я встроенным не пользуюсь, он мне не нравится( Не все без базы, правило проверяются в ней))
Ну я не про RBAC, а про аутентификацию. По-умолчанию там нет базы, user_id в куках тоже. Я ее тоже переписал немного, но в основном что бы усложнить токен, т.е. время туда поставить и т.п., и убрать ненужную информацию которую все-равно получаю из базы. Из-за разделения Identity и WebUser получилось сложновато, но вроде даже совместимо... хотя не проверял серьезно.
 
Сверху