Форум PHP

Эх, а я б цитату вставил :D

зыж
http://softtime.ru/forum/editpostform.php?id_forum=1&id_post=223809&id_theme=38944

Мда.... прочитал сам ;) Красиво сказал, а кнопка "редактироватЬ" не показываеца - сволачь такая :(

Что Вы сейчас сказали?

Ах вот оно что! Но в случае перехвата sid, проще сравнить sid, который лично у меня это имя юзера + пароль + индефикатор всё перемешанное md5 * 75 и его (в моем случае наверное) легче сравнить с таким же sid, который скрипт спокойно может сам сформировать из сессии =)

>Интересное замечание говоришь! Но я не понимаю все крупные, да и не очень движки форумов, cms хранят оные данные в сессии!

Верится с трудом.
Зачем?

Разве так страшно забивать сессию лишней инфой?
Зачем?

Тем более зачем нам его User-Agent и Remote _addr может понадобиться?! Не очень понял.
В случае перехвата SID (случайного или намеренного) и попытки выдать запрос от имени другого пользователя, сравнение этих параметров поможет отклонить неаутентифицированный запрос.

User-Agent и Remote _addr нужен для антиспуфинга.
В БД можно создать таблицу например id, AdminName, AdminPass, AccessLevel
И в поле AccessLevel хранить уровень доступа 0,1,2,3...как сами пожелаете...
при авторизации записываем в $_SESSION['AccessLevel'] значение этого поля.
В скрипты включаем проверку. Если уровень не ниже 2, то .....и т.д.
Это как вариант :)

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

Тем более зачем нам его User-Agent и Remote _addr может понадобиться?!
Если SID перехватит другой человек, то можно сверить его IP/User-Agent и не дать доступ к аккаунту.

Интересное замечание говоришь! Но я не понимаю все крупные, да и не очень движки форумов, cms хранят оные данные в сессии! Разве так страшно забивать сессию лишней инфой? Тем более зачем нам его User-Agent и Remote _addr может понадобиться?! Не очень понял.

Всяко N1.
Во-первых, он будет работать независимо от того, сколько пользователей разрешил Вам создать хостер. Во-вторых, скармливать серверу БД запросы в расчете, что при отсутствии привилегий, он даст по морде - по меньшей мере неосторожно.

Можно, конечно, подстраховаться, и заведя 4 пользователя MySQL (одного для аутентификации и трех других для исполнения действий трех групп пользователей) испускать запросы только в собственных рамках. Но при этом контроль за авторизацией и правами всё равно придется возложить на скрипт. В общем случае число пользователей будет определяться числом групп с различными полномочиями. В MSSQL и Oracle существует сущность Role (очень похожая на группу), в MySQL её придется эмулировать через соотв. пользователя.

но даже при N1 есть замечания.

>пользователь проходит авторизацию мы определим его статус (админ, модератор или user)
храним в сесийных переменных его login и password считываем эти значения в каждом скрипте званого определяем значения статуса для этого пользователя и в зависимости от этого значения разрешаем те или иные действия.

Зачем в сессии хранить login и password пользователя портала?
login и password участвуют в процессе аутентификации, а её пользователь вроде как прошел.
Может лучше хранить идентификатор пользователя и данные user_agent и remote_addr?

Первый способ корректен. В бд у пользователя в одном поле должно быть указано, какой статус он имеет. Не знаю на сколько это праивльно, но я именно так и делал, всё устраивает.