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

[Духовность™]

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

Суть: каждый пользователь, зашедший на сайт, получает сессию с правами доступа. Для анонимных пользователей, зарегистрированных и админов в сессию кладется массив вида действие=>разрешение.

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

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

Есть какие мысли?

 

[Фанат]

не класть в сессию права доступа

 

[Армян]

убить файл сессии

 

[Духовность™]

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

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

 

[флоппик]

М. А просто по факту изменения прав доступа проапдейтить данные в сессии — не комильфо?

 

[Армян]

об этом я както не подумал )

мб когда юзер логинится в базу класть айди сессии? а там уже выборку сделать и удалить все файлы с соотв. именами

 

[Gas]

У меня есть поле в таблице администраторов с датой изменения каких-то важных данных, которые требуют обновления информации в сессии. К этой таблице идёт запрос по primary key при каждом обращении, и если нужно, то достаются обновления из других таблиц.
Но можно и просто всё время вытягивать права или другие данные, имхо, на любителя. А вот идея лезть самому в файлы сессий мне не понравилась.

 

[zerkms]

зачем городить костыли пока нагрузки ещё нет и можно программировать нормально?
вот как появится нагрузка и появятся проблемы - то и будешь искать им решение.

 

[Фанат]

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

 

[zerkms]

*****
мало того, что он простой - так он ещё почти наверняка 99% хитов будет извлекаться из нативного кэша бд.

 

[Духовность™]

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

в какой сессии? программа ничего не знает о сессиях пользователей.

при каждом обращении, и если нужно, то достаются обновления из других таблиц.

ммм. костыли

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

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

о да, переписывать всю систему прав заново?

 

[zerkms]

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

 

[Фанат]

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

 

[Духовность™]

*****
ок, я подумаю тогда как лучше сделать.

 

[atv]

ах, ах, какая несчастная база. от простого запроса тут же упала и умерла.

я пишу говнокод и мой говнокод зачастую очень много запросов использует.

Это какая-то новомодная отмазка, типа "я пишу говнокод, и нормальных решений мне не предлагать"