Внешняя авторизация для НПЖ

Данный модуль позволяет авторизовать пользователей по внешней базе «логин-пароль».

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

Модуль предоставляет архитектуру для реализации связок с произвольными хранилищами и содержит несколько конкретных примеров таких реализаций:

ConfigPrincipal — авторизация по списку логинов-паролей, хранящихся в конфигурационном файле модуля
HackPrincipal — авторизация посредством http-запроса к файлу, защищённому стандартной http-авторизацией.
DbmsMysqlPrincipal и DbmsPostgresPrincipal — авторизация по внешней БД (mysql/postgres), в которой есть таблица c логинами и паролями (пароли могут храниться в шифрованном виде)

Для полноценной работы модуля необходимо устанавливать его на узле, работающим под управлением NPJ R1.9 или выше.

текущий релиз НПЖ.

Авторы

Основной код модуля и авторизаторы ConfigPrincipal и HackPrincipal написаны Kuso Mendokusee — kuso@npj.
Универсальные DbmsMysqlPrincipal и DbmsPostgresPrincipal написаны Norguhtar — sauron@npj.

Maintainer модуля — Kuso Mendokusee, ICQ:136301890.

Скачать

Дистрибутив доступен для скачивания:

Download module Authorize
ZIP, 6 Кб

Если вы — продвинутый разработчик, вы можете воспользоваться и репозиторием кода:

http://cvs.wackowiki.com/trunk/npj_modules/Authorize Subversion ссылки походу не пашут

Только помните, что там может находиться и «не вполне рабочий код».

Зачем нужен модуль?

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

Если список пользователей не пополняется и пароли не секретны — используйте ConfigPrincipal, соответственно его настроив.
Если вы умеете ограничивать своим пользователям доступ к какому-то http-адресу, то настройте его так, чтобы некоторый адрес был открыт только для ваших пользователей и, настройте HackPrincipal для доступа к этому адресу (от вашего узла должны быть разрешены http-запросы к этому адресу, конечно).

Если всё это не подходит — попробуйте написать свой скрипт авторизации.

Краткая инструкция по созданию новых типов провязки с внешней авторизацией

Для того, чтобы «научить» ваш узел работать с внешней авторизацией, вам нужно создать один класс-файл и настроить конфигурационный файл модуля для его использования. Последнее сделать просто — укажите в настройке principal название созданного вами класса. А вот как создавать класс, мы сейчас и расскажем.

Итак, класс должен быть размещён в одноимённом файле (в каталоге classes/ модуля) и быть наследником от NpjCustomPrincipalSuper. С модулем уже поставляются два таких примера — ConfigPrincipal.php и HackPrincipal.php.

Для организации проверки пароля вам нужно перезадать в вашем классе один метод — _GetUserPwd( $login, $pwd ). На вход этому методу приходит пара «логин-пароль», а возвращать он должен одну из констант:

PRINCIPAL_WRONG_LOGIN — если такого логина нет
PRINCIPAL_WRONG_PWD — если логин есть, но пароль не подошёл
PRINCIPAL_AUTH — если авторизация произошла успешно.

Вам также может захотеться записывать какие-то данные в профиль пользователя, если у него ещё не было аккаунта на узле и сейчас он ему автоматически создаётся. Например, ФИО из вашей базы данных. Для этого нужно перезадать метод:

_SpawnAccountData( &$user_data, &$profile_data, $original_login )

Параметры $user_data и $profile_data — это массивы полей, которые будут записаны в таблицы users и profiles соответственно. Вы можете произвольно их видоизменить, придерживаясь схемы БД.

Параметр $original_login — это в точности тот логин, который ввёл пользователь для авторизации.

Какой будет адрес у автоматически созданного аккаунта?

Если кратко, то его-логин@ваш-узел, где

его-логин — это логин, который ввёл пользователь
ваш-узел — это узел, который вы задали в конфигурационном файле модуля, в переменной node_id

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