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

Но вот администратор поменял привилегии или вообще удалил пользователя. Только изменения эти станут актуальны лишь при повторной авторизации. а до тех пор - сессия работает основываясь на данных полученных при login`e

Как можно администратору обнулить конкретную сессию после изменений в базе, чтоб пользвателю пришлось заново входить? (и можно ли вообще?)

Или это делаеться иным способом?

P.s.
всё время лазать в базу и проверяться не хочеться

bE(o0L, а что в твоей системе будет происходить, если в сессии нет каких-то нужных данных (например имени пользователя или его Id)?

система начинает работать только при login`e пользователя, до этого просто приглашение - ввести пароль логин и всё такое.

Только когда пользователь зашёл, пишется сессия со всеми его id username и т.д.
тобишь в сессии не могут отсутствовать данные... вроде

или ты имел ввиду что будет если удалить эту сессию?

тогда всё вернётся к login`у.

bE(o0L писал(а):

Но вот администратор поменял привилегии или вообще удалил пользователя. Только изменения эти станут актуальны лишь при повторной авторизации. а до тех пор - сессия работает основываясь на данных полученных при login`e

У тебя столь остро стоит эта проблема? Really?

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

bE(o0L, эта история звучит фантастично. У клиента сессии живут настолько долго или он просто как полный идиот заранее предупредил секретаршу об увольнении?

Самое очевидное решение: поставить дополнительную проверку, которая выполняется раз в 5 минут. На скорости это не скажется. Время предыдущей проверки сохранишь в сессии.

Crazy, я не вдавался в подробности (нафига?) . Достаточно не закрывать браузер - сессии живут до закрытия.

Дополнительня проверка - да, это вариант.

А если писать id сессии в базу при логине, и сменив привеленгии, удалять физически файл sess_id.… ? где id -идентификатор сессии пользователя.

bE(o0L писал(а):

Дополнительня проверка - да, это вариант.

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

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

Цитата:

Достаточно не закрывать браузер - сессии живут до закрытия.

Это заблуждение.
Рекомендую подучить матчасть

Цитата:

сессии живут до закрытия.

или до:
session_unset()

Цитата:

или до: session_unset()

Это заблуждение.
Рекомендую подучить матчасть

Чебурген, небольшой тест:
http://www.hc-studio.com.ua/test/test_session_unset.php

Вот код файла:

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

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

Ещё я бы порекомендовал время, потраченное на написание тестов, посвятить чтению документации. Но люди редко следуют этому совету, поэтому я не буду настаивать.

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

Чебурген, имелось ввиду переменные конкретной сессии.
timeout там намного больше чем 5 минут.

Имелось в виду, что

Цитата:

сессии живут до закрытия.

что является ложным утверждением.
Но я рад, что ты вспомнил про таймаут.

да, не правельно выразился.
ну бывает!

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

Не думаю, что интенсивность работы админа будет такой сильной, что это "положит" БД своими запросами

mnemonic, это мне НЕ НУЖНО. смотри первый пост.

bE(o0L писал(а):

mnemonic, это мне НЕ НУЖНО. смотри первый пост.

В корне неправильный подход.

bE(o0L писал(а):

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

И о какой вообще тогда безопасности может идти речь? Как говорится, "одно неверное движение и Вы - рут "

и какое же движение по твоему должно быть?

Вдруг Вы еще и в куках запоминаете всю эту инфу для автоматической аутентификации и последующей авторизации пользователя? Знаете такую фичу, типа "запомнить меня [x]"?

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

вы на вопрос ответте.

mnemonic,

Цитата:

И о какой вообще тогда безопасности может идти речь? Как говорится, "одно неверное движение и Вы - рут "

bE(o0L,

Цитата:

и какое же движение по твоему должно быть?

Если можете (знаете). а если нет. тогда зачем все эти глупые домыслы и терзание темы на которую уже был даден ответ и все проблемы устранены.

bE(o0L,

Цитата:

и какое же движение по твоему должно быть?

Если можете (знаете). а если нет. тогда зачем все эти глупые домыслы и терзание темы на которую уже был даден ответ и все проблемы устранены.[/quote]
С удовольствием подискутирую с Вами по поводу безопасности Вашей системы после анализа исходников. В противном случае - пустой разговор

вот я и о том же.
зачем было затевать пустой разговор?

Цитата:

даден

mnemonic писал(а):

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

Т.е. процитированная ниже твоя фраза есть просто гонево? Ok.

Цитата:

И о какой вообще тогда безопасности может идти речь? Как говорится, "одно неверное движение и Вы - рут