Хранение данных пользователя

я и так намекнул тоньше некуда.

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

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

-----
Чем больше узнаю, тем больше я не знаю.

Сессионная кука имеет некий период жизни, а не сама сессия. Об этом вам уже LIME написал. Для примера, я специально залез в папочку с файлами сессий на своем домашнем серваке. Самый древний файл там еще за 12 июля!

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

-----
Все возражают против того, что я гений, хотя никто еще так меня не назвал. - Орсон Уэллс

сессия не может существовать без куки или идентификатора приклееного к URL.


файл, но не сессия.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

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

-----
Все возражают против того, что я гений, хотя никто еще так меня не назвал. - Орсон Уэллс

ну если где то записал ID то да
по идее PHP должен чистить
в этом плане удобно держать сессии в БД или мемкеше
и прибивать кроном

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

а можно GC запускать на каждый запрос
но тут момент
сессию по которой пришел запрос не убьет
она сначала открывается а потом мусор чистится
такая недоработка

GC будет нехило тормозить

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

ну это по идее, на практики же лежит себе спокойно больше месяца

т.е. реализовывать свой механизм сессий...


Кстати, я выяснил причину такой живучести сессионных файлов. Оказывается в PHP5.5.0 значение директивы session.gc_divisor равно 1000. Вобщем GC запускался крайне редко.
Ради эксперимента прописал ini_set('session.gc_divisor', 100), раз 30 обновил страницу, не запустился, поменял на 10, с шестого обновления запустился, стер все кроме текущей сессии.
Для реального проекта, думаю 100 в самый раз. Хотя с хорошей посещаймостью и 1000 будет вполне нормально...

-----
Все возражают против того, что я гений, хотя никто еще так меня не назвал. - Орсон Уэллс

Пяточек, ты уж определись, что ты хочешь (анекдот)


В данном контексте термин "сама сессия" вообще не понятен. Есть кука, с периодом жизни. Есть файл (запись в BD) в котором хранятся данные сессии. И с уверенностью могу сказать, что у тя аппач под виндой стоит. Ссылочку почитай, что я выше давала. Там как раз и про файлы сессий, и про куки сессий, и рукожопых админах.


Тем что:



А зачем он нужен? Он есть в БД удаленных пользователей, он есть в сессии. Наличие его в основной БД уже не требуется.
Все, что ты остальное говоришь, хорошо в теории. Код костыля ты тут привел. Вот только у тебя там прописан ручками SID. Подумай, где ты в реальной жизни брать будешь?

То, что будет читаться файлик при каждом просмотре страниц с сессией, это нет ни что.
Размером он будет не больше килобайта, и жить будет в ОЗУ (в дисковом кеше).


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

механизм тот же - хранилище другое
там есть специальная функция
(Добавление)

термин сессия вполне понятен (тем кто в теме) и не зависит от контекста


не факт - сериализуешь туда класс а он тянет за собой все остальные по ссылке


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

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

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

Какая разница, какого он будет размера и где лежать. Сами подумайте, так мне нужно стартануть сессию и посмотреть, есть ли в ней запись, ну скажем token. Если есть - авторизуем пользователя. Все...
И теперь ваш вариант, стартуем сессию, смотрим, есть ли token, авторизуем пользователя, зачитываем файл, десериализуем, проверяем есть ли в нем этот ID, если есть, грохаем сессию, соответственно права пользователя нужно обновить, удалить этот ID из файла, сериализовать, записать обратно... Дохрена действий и так каждый раз...

С каког это перепуга? Специально для таких упертых как вы попробовал. Скопировал sess_id файла за 12 июля (ну предположим, что я записал это значение из куки когда-то). Теперь пишем куку с этим ID и вуаля, сервак возобновляет эту сессию. Естественно со всеми данными что в ней были.

И что дальше? Это вобще никак к вопросу не относится.

-----
Все возражают против того, что я гений, хотя никто еще так меня не назвал. - Орсон Уэллс

Докажите это хотя бы теоретически.
Это частая ошибка новичка, ожидать от сессии больше того, чем она является в действительности. http://habrahabr[dot]ru/post/171151/

Механизм сессий никак не следит за предельным временем сессии. Пока не пришёл GC - любой запрос с этим SID будет обслужен и продлит время действия сессии. И, конечно, этому запросу будут даны все данные из сессии. Даже если сессия была начата полгода назад (реальный случай из практики).

-----
PostgreSQL DBA

А давайте поставим вопрос несколько иначе.
У кого-нибудь есть фактическая информация о том, сколько юзеров должно быть онлайн, чтобы почувствовать тормоза в работе сайта, если сессии в базе
(Добавление)
PS
Ну а чтобы грохнуть сессию удаленного пользователя, то я думаю можно иметь .ini файл типа
user_id = session_id

пользователь входит - пишем в конец файла его id и его id сессии
пользователь выходит - удаляем запись из файла

удаляем пользователя - узнаем из файла его id сессии, грохаем сессию, удаляем запись из файла, удаляем юзера из БД (ну или метим как удаленного)

-----
ПЫХ тут - ходи туда, прежде чем писать сюда (толку больше будет)

Понятное дело - столько, сколько выдержит сервер СУБД.
На такой банальной нагрузке (операции только по первичному ключу) - счёт на тысячи обращений в секунду. Более того, такой профиль нагрузки ещё и горизонтально масштабируется с лёгкостью. SID же спроектирован так, чтобы иметь равномерное распределение значений - пишете в обработчике, что все SID, начинающиеся с 0-8 - на ту машину, 9-F - на другую. Всё, удвоили ресурсы, а между серверами даже никакая реплика не нужна.

-----
PostgreSQL DBA

Мелкий
Ну вот и я о том же. Для небольшого сайта можно и в базе держать сессии. Ну а для большого можно сделать табличку session с полями
id_user | id_session
Ну в принципе тоже самое, что и выше я описал, но вместо файла табличка в базе

-----
ПЫХ тут - ходи туда, прежде чем писать сюда (толку больше будет)