Logout( $redirect=1 ) — забывание про текущего принципала
$redirect=1 — редирект на ту же страницу
true, is success
Guest( $profile="" ) — инициализация «гостем». $profile указывает на имя файла, которое лежит (примерно) в специально указанной папке и ищется через FindScript $rh.
_Cheat( $login ) — вне зависимости от пароля идентифицируется под пользователя
_UnCheat() — возвращается обратно к предыдущему состоянию
эта пара нужна для проделывания операций от другого лица
не следует использовать эту пару кроме как на глубоких сервисных уровнях
_CheckStoredPassword( $stored_password, $stored_invariant ) — вызывается из Login
проверяет, подходит ли пароль, исходя из выбранной политики
_GenerateStoredPassword() — вызывается из Identify
генерирует пароль для сохранения, исходя из выбранной политики
InvalidateStoredPassword() — инвалидация пароля
Security( $model, $params ) — есть ли доступ у данной персоны согласно модели доступа
$model — объект-потомок PrincipalSecurity
$params = array( key => value )
LoadById($id), LoadByLogin($login, $realm) — загружают структуру принципала из «хранилища», возвращая её. Тут встроено кэширование.
_LoadById, _LoadByLogin — для override в потомках, загружают из БД или из чего там
_Login( $login, $pwd ) — загрузка по логин-пароль
_LoginStored( $login, $stored_pwd ) — загрузка по логин-кука
_StorePassword( $login,$new_stored_invariant ) — сохранение сгенерированной секретной куки в хранилище
_Store(), _Restore() — запись и восстановление данных о принципале в сессию. При этом “cheated” состояния в сессию не записываются и не восстанавливаются.
PrincipalSecurity
Во-первых, в $rh->principal_security = array( “noguests”, “role” ); указывается перечень доступных в данном приложении моделей. Принципал при конструировании создаёт в себе все эти модели. Некоторые методы принципала вызывают специальные рукоятки моделей:
PrincipalSecurity( &$principal )
OnIdentify( &$user_data ) — после успешной идентификации, в сессию не кладём
OnLogin( &$user_data ) — после успешного логина, до складывания в сессию
Check( &$user_data, $params ) — при вызове $principal->Security
во все методы передаётся $user_data — это хэш-массив-строка из БД, соответствующая принципалу
Предлагаемая структура БД
Для пользователей кажется сообразным хранить:
логин/рилм (node_id из NPJ)
пароль/куку/временный пароль и его таймаут
состояние
фио
email и его подтверждённость
когда последний раз логинился в систему
Предлагаемая структура БД:
field
type
user_id*
int
login*
varchar(32)
realm
varchar(32)
password*
varchar(32)
stored_invariant
varchar(32)
temp_password
varchar(32)
temp_timeout
datetime
state/active*
int
name*
varchar(250)
email*
varchar(250)
email_confirm
int
login_datetime
datetime
created_datetime
datetime
created_user_id
int
edited_datetime
datetime
edited_user_id
int
звёздочками помечены поля, которые кажутся мне обязательными во всех моделях «хранилищ» принципала
active or state — не знаю, потому что было state, но для единообразности active кажется лучше. Состояния бывают такие:
0 – отключен, отсутствует или удалён
1 – активный
2 – заморозился сам
3 – забанили администраторы
email_confirm — предлагается код конфирмации генерировать из логина, емайла и секретного слова, так, чтобы для пары «логин+емайл» он был одинаков всегда
семейство created/edited — это моя парадигма хранения метаинформации о правках записи в БД. Моя CMS с этим умела работать и это было забавно. Я бы хотел это не потерять в дальнейшем, могу рассказывать отдельно про это далее.