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

Ваши предложения (в комментах, на форуме или в трекере) приветствуются!

О чем вообще речь?

Модули A1/A2/Acl предназначены для управления правами доступа пользователей. Дистрибутив Kohana v2.3 предоставляет нам только модуль Auth, который позволит контролировать минимальные доступные действия – регистрация, вход (login) и выход (logout). Но ведь помимо этого пользователь взаимодействует с различными объектами (ресурсами) сайта, и эти взаимодействия должны быть каким-то образом регламентированы. Самый простой пример – блог. Гости должны иметь возможность читать записи, авторизованные пользователи также могут комментировать, а администратор (владелец блога) – создавать записи и редактировать комментарии.

Подготовка к работе

Для ветки 2.3.x модули расположены здесь. Нас интересуют модули A1, A2 и Acl, а также демка с примером возможностей модулей A2 и Acl (она называется a2-acl-demo). Просто подкладываем их в папку MODPATH и добавляем в список модулей в config.php. Если запустить метод db контроллера a2demo (http://localhost/a2demo/db), то мы увидим минимально необходимую схему БД для дальнейшей работы с демо-модулем:

CREATE TABLE IF NOT EXISTS `users` (
		  `id` int(12) unsigned NOT NULL auto_increment,
		  `username` varchar(32) NOT NULL default '',
		  `password` char(50) NOT NULL,
		  `token` varchar(32) default NULL,
		  `logins` int(10) unsigned NOT NULL default '0',
		  `last_login` int(10) unsigned default NULL,
		  `role` enum('user','admin') NOT NULL,
		  PRIMARY KEY  (`id`),
		  UNIQUE KEY `uniq_username` (`username`)
		) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
 
		CREATE TABLE IF NOT EXISTS `blogs` (
		  `id` int(12) unsigned NOT NULL auto_increment,
		  `user_id` int(12) unsigned NOT NULL,
		  `text` text NOT NULL,
		  PRIMARY KEY  (`id`),
		  KEY `user_id` (`user_id`)
		) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

Т.е. необходимо создать таблицу для пользователей (она несильно отличается от используемой в Auth) и таблицу для сохранения наших разделяемых ресурсов (т.е. записей блога). Естественно, для настоящего блога эта табличка уж очень неактуальна, но сейчас цель – показать принцип работы модулей. Сами таблицы можно не заполнять – демо-контроллер позволит нам зарегистрироваться и немного поработать над блогом.

Знакомство с демо-версией

Откроем http://localhost/a2demo/. Поскольку мы не представились системе, нам предлагают войти или зарегистрироваться.

Блок авторизации для гостя

Форма для регистрации

Что видит пользователь

А теперь пришло время разобраться, как это все работает.

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

A1: аутентификация

Если Вы знакомы с модулем Auth, то все здесь будет понятно. Библиотека A1 предоставляет базовые методы login(), logout() и get_user(). Все знакомо. Настройка библиотеки хранится в конфигурационном файле (его имя передается в конструктор, по умолчанию ‘a1‘). Там тоже все более-менее понятно, новым для нас будет ключ ‘columns‘:

/**
 * Table column names
 */
$config['columns']   = array(
	'username'	=> 'username',    //username
	'password'	=> 'password',    //password
	'token'    	=> 'token',  			//token
	'last_login'=> 'last_login',  //last login (optional)
	'logins'    => 'logins' 			//login count (optional)
);

Как понятно из названия, тут описываются имена столбцов в БД. Из обязательных только первые три (если не планируется использовать “запоминание” пользователей, то и ‘token‘ не нужен). Это нужно для совместимости со сторонними таблицами пользователей.

В модуле определена абстрактная модель A1_User, от которой необходимо будет наследовать модель для реальной таблицы пользователей (по аналогии с Auth, там была абстрактная модель Auth_User). Имя модели пользователя указывается в параметре ‘user_model‘ (по умолчанию конечно же ‘user‘).

Acl: списки управления доступом

Библиотека Acl пришла в Kohana из фреймворка Zend и предполагает работу с тремя базовыми терминами: роль, ресурс и действие. Например, в условии “редактирование администратором записи в блоге” ролью будет ‘admin‘, действием – ‘edit‘ (редактирование), а ресурсом – запись в блоге (‘blog‘). Термины абстрактны, т.е. под записью в блоге будет рассматриваться любая запись, независимо от условий ее создания (автор, дата и т.д.), а под ролью ‘admin‘ – любой пользователь с данной ролью. Данные три термина объединяются в правила, которые определяют порядок взаимодействия с ресурсами. При этом все, что не разрешено – запрещено.

Сперва объявляем известные нам роли и ресурсы:

// создаем объект Acl
$acl = new Acl;
// добавляем роли
$acl->add_role('guest'); // гость
$acl->add_role('user'); // пользователь
$acl->add_role('admin'); // администратор
// добавляем ресурсы
$acl->add_resource('blog'); // блог
$acl->add_resource('comment'); // комментарий

Правила добавляются с помощью методов allow() и deny() объекта Acl:

// изначально все запрещено
// писать необязательно, привел для примера
$acl->deny(NULL, NULL, NULL);
//  все могут читать все
$acl->allow(NULL, NULL, 'read');
// пользователь и админ могут писать комментарии
$acl->allow(array('user', 'admin'), 'comment', 'write');
// админ может писать в блог
$acl->allow('admin', 'blog', 'write');

В правилах сперва указывается роль (или массив ролей), затем ресурс (или ресурсы), потом – действие (действия). Вместо перечисления всех ролей/ресурсов/действий можно указать NULL (так мы дали права на чтение в примере выше). Есть еще и четвертый параметр, но о нем поговорим отдельно.

Поскольку по умолчанию все запрещено, мы идем по пути “добавляем все, что можно”. Другой вариант – можно разрешить все ($acl->allow(NULL, NULL, NULL)), а затем добавить запрещающие правила. Главный минус – потом можно легко об этом забыть и оставить дыры в защите.

Проверяем права доступа:

var_dump($acl->is_allowed('guest', 'blog', 'write')); // false
var_dump($acl->is_allowed('user', 'comment', 'write')); // true
var_dump($acl->is_allowed('admin', 'blog', 'write')); // true

Использование иерархии

Перечисление всех имеющихся ролей и ресурсов при добавлении правил может превратиться в весьма утомительное занятие. Поэтому библиотека предоставляет возможность построения иерархий с наследованием правил от предка к потомку. Давайте переделаем вышеописанный пример:

// создаем объект Acl
$acl = new Acl;
// добавляем роли
$acl->add_role('guest'); // гость
$acl->add_role('user', 'guest'); // пользователь
$acl->add_role('admin', 'user'); // администратор
// добавляем ресурсы
$acl->add_resource('text'); // абстрактный ресурс
$acl->add_resource('blog', 'text'); // блог
$acl->add_resource('comment', 'text'); // комментарий

Как видно, была построена иерархия ролей (гость -> пользователь -> админ) и ресурсов (текст -> блог и текст -> коммент). Теперь все правила, примененные для гостя, будут доступны и пользователю с админом, а правила для текста могут быть использованы блогом и комментарием. Соответственно так теперь будем добавлять правила:

//  все могут читать все
$acl->allow('guest', 'text', 'read');
// пользователь и админ могут писать комментарии
$acl->allow('user', 'comment', 'write');
// админ может писать в блог
$acl->allow('admin', 'blog', 'write');

Если в правиле указан предок, потомков можно убирать (наследование в чистом виде). В первом правиле я заменил NULL на ‘text‘ – результат тот же, но само правило более четкое. Например, если добавится новый ресурс ‘stats‘, который должен быть разрешен только администраторам, общее правило с NULL позволит любому пользователю получить доступ. В общем, не ленитесь уточнять правила, чтобы потом после разрастания проекта это где-нибудь не аукнулось.

Проверка объектов

До этого мы говорили про абстрактные ресурсы и роли (в виде строк). Однако библиотека поддерживает передачу объектов, например можно использовать что-то вроде $acl->is_allowed($user, 'comment', 'write'); В этом случае объект $user (в данном случае имелся в виду экземпляр ORM-модели User_Model) должен реализовывать интерфейс Acl_Role_Interface, что заключается в наличии метода get_role_id():

class User_Model extends A1_User_Model implements Acl_Role_Interface {
 
	public function get_role_id()
	{// мы должны вернуть значение роли
		return $this->role;
	}

В данном случае возвращается значение поля role, т.к. оно присутствует в реализации библиотеки A1. Если говорить про Auth, там пришлось бы возвращать массив ролей из таблицы roles. Аналогично можно передавать ресурсы, только для них интерфейс называется Acl_Resource_Interface, а необходимый метод – get_resource_id().

class Blog_Model extends ORM implements Acl_Resource_Interface {
 
	public function get_resource_id()
	{
		return 'blog';
	}
}

Assertions

Казалось бы, зачем нам все эти сложности с передачей объектов, если правила Acl поддерживают только абстрактные строки? И вот тут на сцену выходят т.н. assertions (что-то вроде триггеров, дальше я буду использовать именно такой термин). Данные триггеры позволяют совершать дополнительные проверки с полученными объектами. Вот как реализовывается разрешение редактирования собственных комментов пользователем:

$acl->allow('user','comment','edit',array('Acl_Assert_Argument',array('id'=>'user_id')));

В результате при проверке $acl->is_allowed($user, $comment, 'edit') будет выполнена проверка на равенство $user->id и $comment->user_id (т.е. на принадлежность комментария текущему пользователю). Acl_Assert_Argument – это имеющийся в модуле Acl класс, позволяющий связывать между собой поля из моделей роли (в данном случае это модель User_Model, поле id) и ресурса (Comment_Model, поле user_id). Имена полей передаются в виде массива после имени класса. Можно использовать несколько связок, например так:

$acl->allow('user','comment','edit',array('Acl_Assert_Argument',array('id'=>'user_id', 'something_else' => 'other_field')));

Если все пары полей равны между собой, проверка вернет TRUE и доступ будет получен.

Конечно, это очень простой пример триггера, который не может решить всех проблем. Давайте попробуем реализовать простую проверку – создавать блог может только пользователь с количеством комментариев больше 100.

1. Каждый класс-триггер должен реализовывать интерфейс Acl_Assert_Interface. Это заключается в необходимости реализовать метод assert(), объявленный в интерфейсе следующим образом:

public function assert(Acl $acl, $role = null, $resource = null, $privilege = null);

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

class Acl_Assert_Comments implements Acl_Assert_Interface {
	public function assert(Acl $acl, $role = null, $resource = null, $privilege = null)
	{
	}
}

2.Если необходимо предварительно настроить триггер (в примере выше сперва должны были быть созданы соответствия пар полей из объектов роли и ресурса), используем конструктор. При создании правила, как мы помним, передается дополнительный параметр, который мы и будем обрабатывать:

class Acl_Assert_Comments implements Acl_Assert_Interface {
 
	protected $comments_required;
 
	public function __construct($arguments)
	{
		is_array($arguments) AND $arguments = $arguments[0];
		$this->comments_required = intval($arguments);
	}
 
	public function assert(Acl $acl, $role = null, $resource = null, $privilege = null)
	{
	}
}

Мы сохраняем переданное в конструктор значение (количество комментариев для ведения записей в блоге) в свойстве $comments_required. Далее в методе assert() оно будет использовано.
3. Осталось только реализовать сравнение количества комментов у пользователя с сохраненным значением:

class Acl_Assert_Comments implements Acl_Assert_Interface {
 
	protected $comments_required;
 
	public function __construct($arguments)
	{
		is_array($arguments) AND $arguments = $arguments[0];
		$this->comments_required = intval($arguments);
	}
 
	public function assert(Acl $acl, $role = null, $resource = null, $privilege = null)
	{
	    if ($role->comment_count < $this->comments_required) return FALSE;
 
		return TRUE;
	}
}

В данном примере поле comment_count присутствует в таблице users, так как я стараюсь избавиться от регулярного пересчета подобных статистических данных. Естественно, никто не мешает использовать что-то вроде $role->comments->count().

4. Вот и все, триггер создан и работает – можете проверять. Добавление правила будет выглядеть так:

	$acl->allow('user', 'blog', 'comment',  new Acl_Assert_Comments(100));

A2

По сути рассмотренные выше классы A1 и Acl между собой никак не свзяаны – один отвечает за “узнавание” пользователя, а второй “ставит его на место”. Для удобства работы с ними был создан класс-обертка A2. Он является потомком класса Acl и имеет все те же методы для работы с правилами. В качестве дополнения он агрегирует объект A1, что позволяет работать с текущим пользователем напрямую.
Какие методы нам предоставляет класс A2:
1. Разнообразные варианты создания объекта ( __construct(), factory() и instance() ). Все они принимают в качестве единственного параметра $config_name – имя файла конфигурации (об этом чуть ниже).
2. Методы для работы с объектом A1.
2.1. Метод logged_in() перенаправляет вызов к объекту A1, в результате получаем проверку залогиненности пользователя.
2.2. Метод get_user() таким же макаром возвращает сам объект модели пользователя (обычно это User_Model).
3. Метод allowed($resource = NULL, $privilige = NULL) проверяет, может ли текущий пользователь иметь возможность применить к ресурсу $resource действие $privilige. Таким образом, можно не передавать вручную в объект Acl пользователя, а использовать вот такую сокращенную запись.

Конфигурация

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

$config['roles'] = array
(
	'user'			=>	'guest',
	'admin'			=>	'user'
);
 
$config['guest_role'] = 'guest';
 
$config['resources'] = array
(
	'text'			=>	NULL,
	'blog'			=>	'text',
	'comment'		=>	'text',
);
 
$config['rules'] = array
(
	'allow' => array
	(
		array('guest','text','read'),
		array('user', 'comment', 'write'),
		array('admin', 'blog', 'write'),
		array('user', 'blog', 'write', array('Acl_Assert_Comments', array(100))),
	),
);

Все довольно просто и понятно. Параметр $config['guest_role'] определяет имя роли, которая будет использоваться, если никто не залогился. Есть еще один дополнительный параметр, определяющий библиотеку для работы с аутентификацией (я говорил про A1, но ведь и Auth никто не отменял):

$config['a1'] = array('A1');

Если планируется использование другой библиотеки, то необходимо убедиться, что она реализует метод get_user() для получения текущего пользователя, а также использует шаблон Singleton – т.е. имеет статический метод instance(). В качестве параметра после имени библиотеки можно указать аргументы для передачи в метод instance(), обычно это имя конфигурации библиотеки. Сам объект будет сохранен в свойстве $a1 (оно объявлено как public).

Постскриптум

Вот собственно и все. В использовании A2 похожа на Acl, дополнительные возможности я указал. Самая неочевидная ошибка, на которую сам неоднократно напарывался – частенько забывал в моделях ролей и ресурсов реализовывать интерфейсы Acl_Role_Interface и Acl_Resource_Interface – они должны возвращать имя соответственно текущей роли (метод get_role_id()) или ресурса (get_resource_id()).

Кроме того, практически завязанный на ORM модуль Auth также “подвисает”. Включенная в RC3 версия как таковая непригодна к использованию (интересно, зачем Shadowhand вообще добавил его, зная об этом?). Сейчас имеется более-менее работоспособная версия на гитхабе, однако для вместе с ней придется подключать альтернативную версию ORM (это форк от оригинальной, однако сделаны некоторые необходимые изменения, убирающие известные баги). Основные методы (login/logout, “запоминание” пользователя при логине) должны работать.

В ожидании релиза 3.0 не самые радужные перспективы… Будем ждать стабильности в двух популярных модулях.

PS. Кстати, чем радует версия jheathco – наличие описания на вики-странице проекта.

Что внутри?

Загляните в директорию MODPATH/auth:

auth
   |---config
   |       |-----auth.php
   |
   |---libraries
   |       |-----drivers
   |       |           |-----Auth
   |       |           |           |---file.php
   |       |           |           |---orm.php
   |       |           |
   |       |           |-----auth.php
   |       |
   |       |-----auth.php
   |
   |---models
           |-----auth_role.php
           |-----auth_user.php
           |-----auth_user_token.php
           |-----role.php
           |-----user.php
           |-----user_token.php

Конфигурация

Конфигурационный файл config/auth.php содержит немногочисленные настройки модуля:

• $config['driver'] – используемый тип драйвера. В комплекте есть ORM и файлы (file). О них чуть позже.
• $config['hash'] – алгоритм для получения хешей. Нужен для безопасного хранения паролей в хранилище (БД или файлы). По умолчанию sha1, может быть использован любой из списка методов, полученных в результате работы функции hash_algos().
• $config['salt_pattern'] – т.н. “соль” хеша. По сути это номера смещений в строке с паролем, куда будут вставлены дополнительные символы, усложняющие взлом хешированного пароля.
• $config['lifetime'] – время жизни cookie в секундах. Если Вы предоставляете возможность логина с “запоминанием” (т.е. чтобы в следующий раз не вводить заново логин и пароль), то данный параметр определяет время, в течении которого в браузере сохранятся данные. По умолчанию 1209600 секунд (две недели).
• $config['session_key'] – имя ключа для хранения текущего пользователя в сессии. По умолчанию ‘session_key‘ (т.е. будет доступен как $_SESSION['session_key']).
• $config['users'] – массив с первоначально доступными пользователями, если планируется использование драйвера file. По умолчанию пустой, но есть закомментированная строка с пользователем ‘admin‘ и паролем ‘admin‘ (в конфиге хранится не сам пароль, а его хеш).

Класс Auth, как уже было сказано ранее, позволяет работать с различными способами хранения и обработки данных, для этого используются драйверы. Однако имеющийся драйвер на основе файлов имеет очень ограниченные возможности (практически только login/logout), данные о пользователях состоят только их логина и пароля, хранятся в текстовых файлах (точнее в упомянутом ранее $config['users']) и подгружаются все сразу. Поэтому обычно они в документации не фигурируют. А вот ORM-драйвер намного более продуктивен, так что в дальнейшем будем рассматривать только его использование.

Рассмотрим основные возможности библиотеки Auth на примере типовых действий пользователя. Поскольку обычно работа с пользователями проводится во всех контроллерах проекта, удобно в базовом контроллере сохранять экземпляр объекта Auth, чтобы в дальнейшем использовать его как свойство (property) контроллера, например так:

$this->auth = Auth::instance();

Предисловие. Хеши, соли и прочие пряности

Заходу на сайт конечно же должна предшествовать регистрация. А после регистрации пользователя необходимо сохранить пароль, но не в явном же виде! Поэтому используются различные алгоритмы хеширования. В Kohana используется шифрование с применением “соли“, что увеличивает сложность расшифровки хранимого пароля. Давайте рассмотрим такой код:

// в файле config/auth.php
$config['salt_pattern'] = '1, 3, 5, 9, 14, 15, 20, 21, 28, 30';
 
// в тестовом методе
$password = '123456789abcdefg';
echo $this->auth->hash($password)."<br />";
echo $this->auth->hash_password($password);

Данный пример в результате выведет что-то вроде
'e8dabc6b7e1fb46b08d591c66dde7fb783a1dbe4'
'c66692385b1c5aaefef96fc9d94f4a56ee72f63bd8375a4a07'

Если вы несколько раз обновите страницу, то станет заметно, что первая строка не изменяется, а вторая каждый раз разная. Дело в том, что в первой выводится результат простого хеширования введенного пароля (метод hash($password)), он больше ни от чего не зависит. Во втором же случае мы применяем хеширование с “солью“, в результате чего хеш становится совершенно другим.

Итак, это делается в методе hash_password($password, $salt = FALSE). Первый параметр ясен – это пароль в первоначальном виде (нешифрованный). Второй параметр – строка с “солеными” символами. После регистрации данный метод вызывается без параметра $salt, и соль генерируется автоматически (берется хеш от случайного GUID и обрезается до количества элементов в параметре $config['salt_pattern']). Далее самое интересное – соль вставляется в строку с паролем в качестве префикса (т.е. получается $salt.$password) и все это отправляется в метод hash(). Полученный в результате хеш дополнительно разбавляется символами “соли” в местах, указанных параметром $config['salt_pattern'] (например, если в паттерне первым элементом идет единица, то после первого символа пароля будет вставлен один символ “соли“).

Понятно? Если да, то вы наверное ошиблись сайтом. Проще всего рассмотреть пример, показывающий этапы вычисления хеша:

// пароль
$password = '123456789abcdefg';
// соль
$salt = '0000000000';
// соль после хеширования, урезанная до нужной длины
$hashed_salt = substr($this->auth->hash($salt), 0, strlen($salt));
// простой хэш пароля
echo $this->auth->hash($password)."<br />";
// хэш соли
echo $hashed_salt."<br />";
// хэш строки из соли и пароля
echo $this->auth->hash($hashed_salt.$password)."<br />";
// хэш строки из соли и пароля с "вкраплениями соли"
echo $this->auth->hash_password($password, $hashed_salt);

На выходе получим такие строки:

e8dabc6b7e1fb46b08d591c66dde7fb783a1dbe4
8104ba1dc0
0171bfa8e8a0450af6972cc61c6c20407a65bf47
081711b0fa8e48a045b0aaf69712dcc61c6cc200407a65bf47

На первую можете особо не обращать внимание, она просто показывает, насколько далек обычный хеш пароля от полученного с применением “соли“. Вторая строка – это используемый хеш “соли“, из него берутся символы для вставки в хеш пароля. Например, первый символ (цифра восемь) будет вставлен после первого символа пароля (так указано в salt_pattern). Третья строка – это практически итоговый хеш, но до вставки элементов “соли“. Он отличается от хеша просто пароля, т.к. в начало строки была вставлена переменная $hashed_salt. Ну, а между третьей и четвертой строкой даже видно сходство. Итоговый хеш “разбух” еще на 10 символов (столько элементов в salt_pattern), места вставки “крупиц соли” вы легко увидите. Надеюсь, что теперь стало понятнее.

Надеюсь, вы понимаете, что с разной “солью“. получатся разные хеши. Более того, важна не только сама строка с “солью“, но и параметр $config['salt_pattern'].

Еще одно предисловие. Роли

Драйвер ORM предусматривает использование ролей. У каждого пользователя может быть свой набор ролей, определяющий доступные или запрещенные действия. Например, для удачной авторизации помимо совпадения паролей необходимо наличие роли “login“. Это очень удобно, когда надо лишить пользователя возможности войти на сайт, но и удалять неохота (этакий бан). Для входа в “админку” обычно добавляется роль “admin” и т.д. Можно создавать роли и для исключения каких-то действий (например, на запрет написания статей/комментариев или просмотра фотогалерей).

Роли и пользователи между собой взаимодействуют с помощью ORM-моделей Auth_User и Auth_Role. Так как у каждого пользователя может быть несколько ролей, и роль может быть назначена разным пользователям, связь между ними “много-ко-многим” (has_and_belongs_to_many). Напомню, что для работы с таким видом связей в ORM используются методы has(), add() и remove().

Роли в Auth поддерживают метод unique_id($id), поэтому можно использовать конструкции вида ORM::factory(‘role’, ‘login’);

Вход

Пользователь вводит свои логин и пароль, которые передаются формой для обработки контроллером. Для проверки корректности введенных данных существует метод login($username, $password, $remember = FALSE). Первые два параметра понятны, третий – та самая “галочка” для автоматического входа в дальнейшем. В нашем контроллере проверка будет происходить примерно так:

if ($post = $this->input->post())
{
	// в $_POST есть данные, значит кто-то пытается войти
	if ( ! $this->auth->login($post['username'], $post['password'], $post['rememberme']))
	{
		// логин не удался, лучше всего перезагрузить страницу
		url::redirect(Router::$current_uri);
	}
	else
	{
		// вошли на сайт! Надо перенаправить пользователя
		url::redirect();
	}
// иначе просто показываем форму для входа на сайт
}

Метод login() возвращает булевский результат TRUE/FALSE, в зависимости от которого мы либо можем смело обрабатывать пользователя как залогиненного (как правило это редикт обратно на страницу, откуда был совершен переход к форме входе), либо доложить об ошибке и предложить попробовать еще (опять же, делаем редирект на текущий URL, чтобы очистить массив $_POST). В первой строчке проверяется наличие POST-данных вообще, так как удобно совместить в данном методе как просто вывод формы входа, так и авторизацию.

А что происходит внутри метода login()? Давайте заглянем.

Пустые пароли не поддерживаются вообще (метод сразу возвращает FALSE).
Далее необходимо сравнить пароли. Так как в БД пароль хранится в захешированном виде, надо сравнивать хеши паролей. Как уже было сказано выше, если не знать “соль“, использованную при первом хешировании, второй хеш того же пароля получится совершенно другим. Поэтому для извлечения “соли” из готового хеша используется метод find_salt($password). Он использует указанный в конфигурации шаблон (salt_pattern) и выдергивает из хранящегося хэша символы.

Теперь наверное станет понятно, почему смена salt_pattern приводит к потере аккаунтов – невозможно получить правильную “соль” из старых паролей. Это очень распространенная ошибка, даже занес ее в свой FAQ…

Далее все просто – сравниваем полученный хеш со старым и выдаем вердикт. В качестве бонуса различные драйверы могут выполнять дополнительные действия в случае, если логин успешный. Например, драйвер ORM дополнительно проверяет, есть ли у пользователя права на логин (для этого предусмотрены роли), надо ли запомнить данного пользователя, увеличивает счетчик входов и сохраняет время последнего логина. Кроме того, в сессии (под именем, указанным в config['session_key']) сохраняется объект с данными пользователя (для драйвера ORM это объект класса User_Model).

Проверка авторизации

Конечно, заставлять пользователя вводить логин и пароль на каждой странице глупо. Модуль Auth позволяет проверять, вошел ли на сайт пользователь или он еще пока гость. Для этого есть “висящий” в сессии объект User_Model и метод logged_in().

На самом деле logged_in($role), как видно из имени параметра, позволяет проверить не только сам факт авторизации, но и наличие требуемой роли. Если в сессии присутствует объект User_Model и выполняется условие наличия у данного объекта всех запрошенных ролей (параметр $role может быть и массивом ролей), то возвращается TRUE. Соответственно, можно не передавать имя роли в данный метод, будет анализироваться только содержимое сессии.

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

$this->user = $this->auth->get_user();

Метод get_user() возвращает объект User_Model из сессии, если он там есть. Иначе FALSE.

Выход

Для выхода с сайта используется метод logout($destroy = FALSE), который уничтожает объект User_Model из сессии, а также может и разрушить саму сессию (если параметр $destroy установлен в TRUE). В принципе достаточно вызова logout() без параметров. Метод возвращает TRUE/FALSE, в зависимости от успешного удаления объекта из сессии.

Автологин

Если используется параметр $remember при авторизации, модуль Auth пытается сохранить данные пользователя на указанное в config['lifetime'] время. Вот тут-то нам пригодится стоявшая до сих пор в сторонке модель Auth_User_Token_Model (я не знаю достойного перевода для термина ‘token’, поэтому в дальнейшем буду его использовать как есть). Token по сути представляет из себя некий идентификатор длиной 32 символа, который сохраняется в базе данных и в куках браузера. Таким образом, в пределах времени жизни куки есть возможность сравнить эти значения и если все совпало, то дать возможность автоматически авторизоваться без ввода пароля. Для этого в объекте User_Token_Model есть связь “один-ко-многим” с User_Model (в виде поля user_id).

Дополнительные сведения про token:

• После каждого автоматического входа кука с User_Token_Model обновляется (в целях безопасности меняется идентификатор). Естественно обновляется и запись в БД.
• Примерно каждый сотый token инициирует “чистку мусора” – запрос к БД, удаляющий все записи с истекшим сроком хранения.
• Хранится в куке с именем ‘authautologin‘.
• При выходе (logout) кука удаляется – в следущий раз придется авторизовываться “как все”.

Если вы хотите использовать возможность автовхода, сразу после проверки методом logged_in() добавьте вызов метода auto_login():

if ($this->auth->logged_in())
{
// пользователь авторизован
}
elseif ($this->auth->auth_login())
{
// у пользователя есть кука и автологин прошел успешно
}
else
{
// у нас гость
}

Вход без пароля

В модуле есть и “черный вход” – метод force_login($user), позволяющий без ввода пароля авторизоваться под указанным пользователем. Может быть полезно для взгляда на проект “чужими глазами”, но лишний раз играться с такими методами опасно (ИМХО). После такого входа в сессии появляется флаг ‘auth_forced‘, установленный в TRUE. Его надо анализировать перед выполнением каких-либо серьезных изменений в проекте.

Вроде бы все, удачных вам авторизаций!

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

Настройка

Скопируйте модули и контроллер в соответствующие папки. В application/config/config.php не забудьте подключить модули. Кроме того, рекомендую закомментировать модуль Auth и проверить, нет ли в application/models моделей Auth и Blog (они присутствуют в модуле A2), т.к. они будет загружены вместо необходимым нам. Для работы прилагаемого демо-контроллера необходимы две таблицы, одна для пользователей, другая для контролируемого ресурса (блоги):

	CREATE TABLE IF NOT EXISTS `users` (
	  `id` int(12) UNSIGNED NOT NULL AUTO_INCREMENT,
	  `username` varchar(32) NOT NULL DEFAULT '',
	  `password` char(50) NOT NULL,
	  `logins` int(10) UNSIGNED NOT NULL DEFAULT '0',
	  `last_login` int(10) UNSIGNED DEFAULT NULL,
	  `role` enum('user','admin') NOT NULL,
	  PRIMARY KEY  (`id`),
	  UNIQUE KEY `uniq_username` (`username`)
	) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
 
	CREATE TABLE IF NOT EXISTS `blogs` (
	  `id` int(12) UNSIGNED NOT NULL AUTO_INCREMENT,
	  `user_id` int(12) UNSIGNED NOT NULL,
	  `text` text NOT NULL,
	  PRIMARY KEY  (`id`),
	  KEY `user_id` (`user_id`)
	) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

Поскольку таблица с пользователями у меня уже была, я просто добавил поле `role` и убрал в существующем поле `email` атрибут NOT NULL (данное поле в демо использоваться не будет). Если таблица `users` у вас тоже есть, не забудьте в файле modules/a1/config/a1.php привести настройки (метод хэширования, “соль” и т.д.) в соответствие с теми, что были в auth.php (он либо в application/config/, либо в modules/auth/config).

Вот собственно и все. Запускаем http://localhost/a2demo/ и видим предложение представиться/зарегистрироваться, а также сообщение, что блогов нет. Сперва войдем на сайт под существующем логином или зарегистрируемся. Тут все более-менее похоже на модуль Auth, разве что в выводимой Profiler‘ом информации на удивление мало запросов, связанных с пользователем (как мы помним, Auth делал три запроса).

Управление объектами

Так для чего же нам нужны эти две дополнительные библиотеки? Если вы еще не знакомы с Zend_Acl, самое время немного почитать. В общих чертах, Acl (списки доступа) – это некий набор типовых правил (“разрешить то-то”/”запретить то-то”), применяемых к отдельным классам ресурсов (в нашем случае это блоги) для текущего пользователя (точнее, для имеющихся у пользователя ролей). Так, в конфигурационном файле a2.php приведены правила следующего вида:

$config['rules'] = array
(
	'allow' => array
	(
			// guest can read blog
		array('guest','blog','read'),
		...
	),
...
}

Первый параметр – роль, второй – класс ресурса, далее имя операции. Все это разрешается (т.к. ключ “allow“). Аналогично существуют правила для запрета операций. Кроме того, роли пользователей выполнены в виде иерархии Гость->Пользователь->Админ с наследованием правил. Еще одна возможность – использование утверждений (asserts). Это правила с добавлением условий их применения (таким образом реализована проверка владельца блога при редактировании). Все правила загружаются из файла, а не из БД, хорошо это или плохо – решать вам. Мне кажется, с разрастанием приложения могут возникнуть проблемы…

А что насчет A2? Дело в том, что нас не всегда устраивают разрешения для целого класса ресурсов. Для отдельных экземпляров объектов в A2 можно применить отдельные правила. Для этого вместо строкового названия ресурса можно использовать экземпляр конкретного ресурса (например, ORM::factory(‘blog’,1), т.е. блог с идентификатором 1).

Помимо настроек в конфигурационном файле мы можем редактировать правила прямо в демо-контроллере:

// разрешаем редактирование всех блогов админами
$this->a2->allow('admin', 'blog', 'edit', NULL);
// добавляем для пользователей право на удаление блога с id=1
$this->a2->allow('user', ORM::factory('blog', 1), 'delete', NULL);
// запрещаем чтение блогов ВСЕМ пользователям (правила наследуются)
$this->a2->deny('guest', 'blog', 'read', NULL);

Итог

Получилось несколько сумбурно, но, надеюсь, что основную мысль я до вас донес. В любом случае скоро нам придется попробовать применить данный модуль вместо тяжеловесного Auth. И если не выявится еще какой-либо более интересный модуль, мы будем использовать именно связку A1+A2.

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

Входит и выходит… Замечательно выходит!

Итак, после прошлой статьи у нас имеется контроллер Auth_Controller. Давайте добавим методы login и logout:

  public function login() {
    $errors = array();
    if ($this->input->post()) {
      // введены данные формы
      if (Auth::instance()->login($_POST['username'], $_POST['password'])) {
        url::redirect(url::base(FALSE).'auth/profile');
      }
      else $errors['login'] = 'login failed!';
    }
    $this->template->content = new View('auth/login');
    $this->template->title = 'Авторизация пользователя';
    $this->template->content->errors = $errors;
  }
 
    public function logout() {
      if (Auth::instance()->logout()) {
        url::redirect(url::base(FALSE).'auth/login');
      }
    }

Все довольно просто. Проверяем входные данные (массив $_POST), если есть – пробуем войти. Используются методы login() и logout() объекта Auth (доступ к которому мы получаем через Auth::instance(), налицо реализация паттерна Singleton). В методе login() используется представление application/views/auth/login.php:

<?php defined('SYSPATH') OR die('No direct access allowed.'); ?>
<form action='<?=url::base(FALSE)?>auth/login' id='login' method='post'>
<fieldset>
  <legend>Авторизация пользователя</legend>
  <div id='errors'><?foreach($errors as $key=>$val):?><p><?=$key.":".$val?></p><? endforeach?></div>
  <ol>
    <li><label for='username'>login </label><input type='text' name='username' id='username' size="20" maxlength="32" /></li>
    <li><label for='password'>password </label><input type='password' name='password' id='password' size="20" maxlength="50" /></li>
    <li><input type="submit" value="Войти" /></li>
  </ol>
  <a href='/auth/register'>Зарегистрироваться</a>
</fieldset>
</form>

Все вроде стандартно. Но попробуйте войти под правильной комбинацией логина и пароля – нас перенаправит на страницу профиля… и все. Мы даже не можем определить, вошли мы или нет. Вывод: надо еще на каждой странице определять статус пользователя и отображать его где-то (я предпочитаю в “шапке” сайта). Давайте подумаем, как это можно сделать.

• Во-первых, объект Auth после логина пользователя сохраняет в сессии экземпляр модели User_Model (в случае ORM), имя ключа указывается в параметре $config['session_key'] (т.е. по умолчанию получаем $_SESSION['auth_user']). Для любителей самостоятельно поковырять исходники – смотрите файл modules/auth/libraries/drivers/auth.php, метод complete_login().
• Во-вторых, поскольку необходимо иметь доступ к данным пользователя на каждой странице сайта, проще всего создать переменную в таком контроллере, от которого будут наследоваться все остальные контроллеры страниц. Давайте назовем его Web_Controller (файл application/controllers/web.php):
  

  <?php defined('SYSPATH') OR die('No direct access allowed.');
   
  class Web_Controller extends Template_Controller {
    public $template = 'index';
    public $user = FALSE;
   
    public function __construct() {
      parent::__construct();
      $this->template->login = 'test';
      if(!Auth::instance()->logged_in('login')) {
        $this->template->login = new View('header/guest');
      }
      else {
        $this->user = $_SESSION['auth_user'];
        $this->template->login = new View('header/logged');
        $this->template->login->login = $this->user->username;
      }
      $this->template->menus = array
        (
            array
            (
                'title'   =>  'Главная страница блога',
                'link'    =>  url::base(FALSE).'blog/',
            ),
        );
    }
   
  }

Итак, мы вынесли в базовый контроллер проверку, вошел ли пользователь, результат хранится в переменной $this->user. В зависимости от этого мы в шапку сайта вставляем предложение войти либо информацию о текущем пользователе и пару ссылок (“Профиль” и “Выйти”). Попутно закинули инициализацию массива ссылок для меню правой части нашего шаблона (на самом деле элементы интерфейса могут зависеть от текущего контроллера/метода, но это уже оффтоп). Для работы кода понадобятся представления.

application/views/header/logged.php

<?php defined('SYSPATH') OR die('No direct access allowed.'); ?>
Вы - <strong><?=$login?></strong>. <a href='<?=url::base(FALSE)?>auth/profile'>Профиль</a>. <a href='<?=url::base(FALSE)?>auth/logout'>Выйти</a>

application/views/header/guest.php

<?php defined('SYSPATH') OR die('No direct access allowed.');?>
<a href='<?=url::base(FALSE)?>auth/login'>Войти</a>

Не забываем, что теперь надо все используемые контроллеры наследовать не от Template_Controller, как раньше, а от Web_Controller. Ну и по-хорошему надо бы анализировать предыдущий URL, с которого пользователь выходил на страницы с login/logout, чтобы перенаправлять его обратно.

Далее еще немного подумаем. Если пользователь залогинен, то ему бессмысленно попадать на страницу авторизации, поэтому добавим в самое начало метода login() такую строчку:

$this->user AND url::redirect(url::base(FALSE).'auth/profile');

Редирект произойдет только если переменная $this->user содержит информацию о текущем пользователе. Добавим такую же проверку в метод register(), а также по аналогии изменим logout():

$this->user OR url::redirect(url::base(FALSE).'auth/login');

Заполняем анкету

Конечно, страница профиля смотрится бедненько, точнее совсем не смотрится. Предлагаю дать возможность пользователю ввести дополнительную информацию о себе (ФИО, телефон и т.д.). Для этого надо создать отдельную таблицу user_details. Почему я не хочу расширить существующую таблицу users? Дело в том, что анкетные данные – информация скорее справочная, и так часто использоваться не будет. А вот из users данные будут браться чаще (как минимум при login/logout), да и хранить в сессии лишние данные (ведь у нас там User_Model) как-то неохота. Поэтому решено – создаем отдельную таблицу:

DROP TABLE IF EXISTS `user_details`;
CREATE TABLE  `user_details` (
  `user_id` int(10) UNSIGNED NOT NULL,
  `first_name` varchar(127) DEFAULT NULL,
  `last_name` varchar(127) DEFAULT NULL,
  `middle_name` varchar(127) DEFAULT NULL,
  `interests` varchar(127) DEFAULT NULL,
  `about` varchar(255) DEFAULT NULL,
  `icq` varchar(10) DEFAULT NULL,
  `jabber` varchar(127) DEFAULT NULL,
  `website` varchar(127) DEFAULT NULL,
  `city` varchar(127) DEFAULT NULL,
  PRIMARY KEY  (`user_id`),
  CONSTRAINT `FK_user_details_1` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Создали несколько полей, связали с таблицей `users` внешним ключом (т.к. связь один-к-одному, то user_id является и первичным ключом). Все поля, кроме user_id, являются необязательными.

Какой следующий этап? Вспоминаем, какие компоненты MVC используются для предоставления данных из БД – правильно, модели. Надо создать модель (конечно, это будет ORM-модель), предоставляющую возможность работать с таблицей user_details. Все это несложно:

файл application/models/User_Detail.php

<?php defined('SYSPATH') OR die('No direct access allowed.');
 
class User_Detail_Model extends ORM {
 
    // Relationships
    protected $has_one = array('user');
 
    protected $primary_key = 'user_id';
 
   /**
	 * Validates and optionally saves a new user record from an array.
	 *
	 * @param  array    values to check
	 * @param  boolean  save the record when validation succeeds
	 * @return boolean
	 */
	public function validate(array & $array, $save = FALSE)
	{
		$array = Validation::factory($array)
			->pre_filter('trim')
      ->add_massive_rules(array('first_name', 'last_name', 'middle_name'),
          'length[2,127]', 'chars[\pL -\']')
      ->add_massive_rules(array('interests', 'city'), 'length[2,127]', 'standard_text')
      ->add_rules('website', 'url', 'length[2,127]')
      ->add_rules('icq', 'length[2,10]', 'chars[\pN-]')
      ->add_rules('about', 'length[2,255]', 'standard_text')
      ->add_rules('jabber', 'length[2,127]', 'email');
		return parent::validate($array, $save);
	}
}

Разбираемся. В ORM-моделях необходимо описывать связи с другими таблицами в виде свойств ($has_one, $has_many, $belongs_to, $has_and_belongs_to_many), имена которых говорят сами за себя. Так как связь с таблицей users один-к-одному, то мы вписываем имя таблицы в свойство $has_one. Таким образом, информация о пользователе из данной таблицы будет доступно через “магическое” свойство users (например, $userdata->users). Идем дальше. Одно из стандартных требований ORM – первичные ключи должны иметь имя `id`. Но есть и обходной путь – свойство $primary_key позволяет нам задать другое имя для первичного ключа, чем мы и пользуемся.

Из методов необходимо только описать валидацию данных, т.к. в ней описываются требования к вводимым данным. Обратите внимание на использование нашего “напильникового” метода add_massive_rules (мы его создавали в этой статье). Также стоит пристальнее глянуть на правила вида ‘chars[\pL -\']‘ – о том, как я к ним пришел, можно почитать здесь.

Далее, надо создать метод контроллера для редактирования анкеты пользователя. Назовем его change_profiile():

public function change_profile() {
      $this->user OR url::redirect(url::base(FALSE).'auth/login');
      $errors = $data = array();
      $userdata = ORM::factory('user_detail', $this->user->id);
      if ($this->input->post()) {
        // введены данные формы
        $data = array(
          'first_name' =>   '',
          'last_name' =>    '',
          'middle_name' =>  '',
          'city' =>         '',
          'interests' =>    '',
          'about' =>        '',
          'website' =>      '',
          'icq' =>          '',
          'jabber' =>       '',
        );
        $data = arr::overwrite($data, $_POST);
        if (!$userdata->validate($data)) {
          $errors = $data->errors();
        }
        else {
          $userdata->user_id = $this->user->id;
          if ($userdata->save())
            $errors['Result'] = 'Change_profile.Succesfull';
          else $errors['Result'] = 'Change_profile.Error';
        }
      }
      $this->template->content = new View('auth/edit_profile');
      $this->template->title = 'Ваша анкета';
      $this->template->content->userdata = arr::overwrite(arr::merge($this->user->as_array(), $userdata->as_array()), $data);
      $this->template->content->errors = $errors;
    }

В самом начале скрипта проверяем, вошел ли пользователь (т.к. у гостя профиля нет и редактировать ему нечего). Для заполнения массива $data только нужными нам значениями использовали функцию arr::overwrite(), которая позволила скопировать из $_POST только значения полей ,перечисленных в $data. Далее создается модель User_Detail через метод ORM::factory(). Для выборки данных передается первичный ключ – идентификатор текущего пользователя. В случае успешного прохождения валидации состояние модели $userdata сохраняется с помощью метода save().

Обратите внимание, что поля, не участвующие в валидации, необходимо добавить в модель вручную! Так пришлось поступить с первичным ключом user_id.

Для вывода результата работы скрипта заполняются переменные шаблона content: $userdata (общая информация о пользователя, включая некорректно введенные в форму данные) и $errors (ошибки и сообщения валидации).

Ну и напоследок приведу текст шаблона:
Файл application/views/auth/edit_profile.php

<?php defined('SYSPATH') OR die('No direct access allowed.');?>
<h2>Информация о пользователе <?=$userdata['username']?></h2>
<form action="<?=url::base(FALSE)?>auth/change_profile" id="login" method="post">
<div id="errors"><?foreach($errors as $key=>$val):?><p><?=$key.":".$val?></p><? endforeach?></div>
<fieldset>
  <legend>Личные данные</legend>
  <ol>
    <li>
      <label for="first_name">Фамилия </label>
      <input type="text" name="first_name" id="first_name" size="20" maxlength="127" value="<?=$userdata['first_name']?>" />
    </li>
    <li>
      <label for="last_name">Имя </label>
      <input type="text" name="last_name" id="last_name" size="20" maxlength="127" value="<?=$userdata['last_name']?>" />
    </li>
    <li>
      <label for="middle_name">Отчество </label>
      <input type="text" name="middle_name" id="middle_name" size="20" maxlength="127" value="<?=$userdata['middle_name']?>" />
    </li>
    <li>
      <label for="city">Город </label>
      <input type="text" name="city" id="city" size="20" maxlength="127" value="<?=$userdata['city']?>" />
    </li>
  </ol>
</fieldset>
<fieldset>
  <legend>Контакты</legend>
  <ol>
    <li>
      <label for="website">Сайт </label>
      <input type="text" name="website" id="website" value="<?=$userdata['website']?>" size="20" maxlength="127" />
    </li>
    <li>
      <label for="icq">ICQ </label>
      <input type="text" name="icq" id="icq" value="<?=$userdata['icq']?>" size="20" maxlength="10" />
    </li>
    <li>
      <label for="jabber">Jabber </label>
      <input type="text" name="jabber" id="jabber" value="<?=$userdata['jabber']?>" size="20" maxlength="127" />
    </li>
  </ol>
</fieldset>
<fieldset>
  <legend>Дополнительно</legend>
  <ol>
    <li>
      <label for="interests">Интересуюсь </label>
      <input type="text" name="interests" id="interests" value="<?=$userdata['interests']?>" size="20" maxlength="127" />
    </li>
    <li>
      <label for="about">О себе </label>
      <textarea name="about" id="about" rows="3" ><?=$userdata['about']?></textarea>
    </li>
    <li><input type="submit" value="Сохранить" /></li>
  </ol>
</fieldset>
</form>

Думаю, стоит сделать небольшой перерыв, дабы все это проверить и осмыслить

Update. Конечно, постоянно хранить в сессии весь ORM-объект совсем необязательно. В принципе, нам потребуется id и username (его мы показываем в “шапке”), а уже если в какой-то момент потребуется проверить уровень доступа, тогда на основании id конструировать модель и проверять наличие нужной роли через метод has().

Update2. Как правильно заметил Алексей (Alex_XS), теперь после регистрации пользователей можно их перенаправлять сразу на редактирование анкеты (т.е. url::redirect(‘auth/change_profile’)).

Update3. Выложил архив с классами по итогам двух уроков с модулем Auth. Обратите внимание, что мы переопределили процесс валидации пользователя (models/auth_user.php) и создали новый метод add_massive_rules для объекта Validation (файл libraries/MY_Validation.php).

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

Как вы могли заметить, к дистрибутиву фреймворка прилагается (если вы конечно поставили галочку в нужном месте при загрузке Kohana) модуль Auth. В нем уже реализованы базовые механизмы аутентификации и авторизации, нам останется только научиться их использовать. Итак, в путь.

Первоначальная настройка

Сам модуль располагается в modules/auth. Сперва необходимо скопировать файл modules/auth/config/auth.php в папку application/config/ (думаю, понятно зачем). Внутри находятся настройки модуля, из которых мы выделим следующие:

$config['driver'] = 'ORM';
$config['hash_method'] = 'sha1';
$config['salt_pattern'] = '1, 3, 5, 9, 14, 15, 20, 21, 28, 30';

Сперва указывается используемый драйвер (в поставке есть выбор между ORM и файловым). Насколько я смог понять из исходников, при выборе файлового драйвера пользователи просто хранятся в массиве $config['users'] в виде сочетания ИМЯ=>ХЭШ_ПАРОЛЯ. Поэтому мы будем использовать всю мощь связки ORM+БД.

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

Ну, и напоследок – соль. Простое получение хэша от введенного пароля не является безопасным способом, поэтому используют дополнительные куски текста для формирования более стойких хэшей. Суть в том, что перед указанными нами позициями (по умолчанию до первой, третьей и т.д. – и не забываем, что смещение в строке отсчитывается с нуля) вставляются символы, “разбавляющие” хэш самого пароля. В итоге, не зная конкретного расположения “крупинок соли”, тяжело вломать хэш. Лучше изменить настройку salt_pattern по умолчанию, но не забывайте, что это надо делать до регистрации пользователей, т.к. меняется алгоритм расчета хэшей. Также помним, что стандартно функция hash() возвращает 40-символьную строку, поэтому указывать смещения 40 и более бессмысленно.

Создаем таблицы в БД

Модуль Auth с драйвером ORM потребует от нас создания нескольких таблиц. К сожалению, в Kohana версии 2.3.1 уже не поставляется демо-контроллер Auth_Demo, в котором, в частности, был приведен текст SQL-запросов для этих самых таблиц. Приведу текст запросов из версии 2.3:

CREATE TABLE IF NOT EXISTS `roles` (
  `id` int(11) unsigned NOT NULL auto_increment,
  `name` varchar(32) NOT NULL,
  `description` varchar(255) NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `uniq_name` (`name`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
 
INSERT INTO `roles` (`id`, `name`, `description`) VALUES(1, 'login', 'Login privileges, granted after account confirmation');
INSERT INTO `roles` (`id`, `name`, `description`) VALUES(2, 'admin', 'Administrative user, has access to everything.');
 
CREATE TABLE IF NOT EXISTS `roles_users` (
  `user_id` int(10) unsigned NOT NULL,
  `role_id` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`user_id`,`role_id`),
  KEY `fk_role_id` (`role_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
CREATE TABLE IF NOT EXISTS `users` (
  `id` int(11) unsigned NOT NULL auto_increment,
  `email` varchar(127) NOT NULL,
  `username` varchar(32) NOT NULL default '',
  `password` char(50) NOT NULL,
  `logins` int(10) unsigned NOT NULL default '0',
  `last_login` int(10) unsigned,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `uniq_username` (`username`),
  UNIQUE KEY `uniq_email` (`email`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
 
CREATE TABLE IF NOT EXISTS `user_tokens` (
  `id` int(11) unsigned NOT NULL auto_increment,
  `user_id` int(11) unsigned NOT NULL,
  `user_agent` varchar(40) NOT NULL,
  `token` varchar(32) NOT NULL,
  `created` int(10) unsigned NOT NULL,
  `expires` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `uniq_token` (`token`),
  KEY `fk_user_id` (`user_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
 
ALTER TABLE `roles_users`
  ADD CONSTRAINT `roles_users_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE,
  ADD CONSTRAINT `roles_users_ibfk_2` FOREIGN KEY (`role_id`) REFERENCES `roles` (`id`) ON DELETE CASCADE;
 
ALTER TABLE `user_tokens`
  ADD CONSTRAINT `user_tokens_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE;

Для наделения пользователей определенными правами будут использоваться роли. Сразу создаются две стандартные роли – login (собственно эта роль дает право входить на сайт под этим логином) и admin (тут все понятно). Обратите внимание на имена таблиц и полей, в частности внешних ключей – это одно из требований ORM Kohana (в ближайшем будущем планирую написать статью об этом чуде).

Пробуем зарегистрироваться

Итак, сперва было яйцо… Или курица… В общем, в начале должно быть что-то, от чего нам отталкиваться, и это конечно регистрация пользователя. Давайте накидаем код:

<?php defined('SYSPATH') OR die('No direct access allowed.');
 
class Auth_Controller extends Template_Controller {
  public $template = 'index';
 
  public function __construct() {
    parent::__construct();
    $this->template->menus = array
    (
      'main' => array
      (
        'title'   =>  'Главная страница блога',
        'link'    =>  '/blog/',
      ),
      'article' => array
      (
        'title'   =>  'Статья "Наша первая страница на Kohana"',
        'link'    =>  '/2009/01/12/',
      ),
    );
    $this->template->login = '';
  }
 
  public function index() {
    url::redirect(url::base(FALSE).'auth/register');
  }
 
  public function register() {
    $this->template->title = 'Регистрация нового пользователя';
    $this->template->content = new View('auth/register');
    if ($this->input->post()) {
        // введены данные формы
        $errors = $data = array(
          'email' => '',
          'email_confirm' => '',
          'username' => '',
          'password' => '',
          'password_confirm' => '',
        );
        $data = arr::overwrite($data, $_POST);
        $user = ORM::factory('user');
        if (!$user->validate($data))
          $errors = $data->errors();
        else {
          $user->add(ORM::factory('role', 'login'));
          if ($user->save())
            url::redirect(url::base(FALSE).'auth/profile');
            else {
              $errors['register'] = 'Ошибка создания пользователя';
            }
        }
    }
    else $errors = $data = array();
    $this->template->content->errors = $errors;
    $this->template->content->postdata = is_object($data) ? $data->as_array() : $data;
  }
 
  public function profile() {
    $this->template->title = 'Профиль пользователя';
    $this->template->content = 'Пользователь зарегистрирован!';
  }
}

В конструкторе мы заполняем парочку переменных для шаблона index (вспоминаем первую страницу на Kohana). На будущее создаем еще переменную login в шаблоне – мы же захотим, чтобы имя залогиненного пользователя было видно на странице. По умолчанию мы перенаправим пользователя сразу на страницу регистрации (конечно это неправильно, но у нас пока будет так). Обратите внимание на url::base(FALSE) – мы считываем путь к корню сайта, т.к. не всегда сайт располагается в корне.

Самое интересное хранится в методе register. Условие if ($this->input->post()) проверяет наличие данных в глобальном массиве $_POST (наша форма регистрации будет передавать их именно через него, привыкайте к правилу “данные меняются только через POST”). Далее мы инициализируем массивы для хранения ошибок ($errors) и самих данных ($data). Зачем делать именно так, мы видим уже на следующей строке:

$errors = $data = array(
          'email' => '',
          'email_confirm' => '',
          'username' => '',
          'password' => '',
          'password_confirm' => '',
        );
$data = arr::overwrite($data, $_POST);

Если посмотреть в документацию, узнаем, что arr::overwrite() позволяет перезаписать данные из второго параметра в первый, но только по существующим в первом массиве ключам. Т.е. если бы массив $data был пустым, ничего в него бы не записалось. Аналогично с массивом $errors, но его мы заполним позже. Почему именно эти поля? Вспомним заметку в “Напильнике” о доработке объекта Auth_User. Там разбирались правила, назначаемые полям, вводимым пользователем. Соответственно и ошибки могут быть связаны только с этими полями.

Следующий кусок:

$user = ORM::factory('user');
if (!$user->validate($data))
   $errors = $data->errors();
else {
   $user->add(ORM::factory('role', 'login'));
   if ($user->save())
      url::redirect(url::base(FALSE).'auth/profile');
   else $errors['register'] = 'Ошибка создания пользователя';
}

Здесь мы создаем экземпляр модели User (если посмотрите исходники, то увидите, что это расширение модели Auth_User) и проверяем его на валидность, передавая в качестве входных данных массив $data. Если валидация успешна, дополняем данные пользователя ролями (точнее одной ролью ‘login’, она необходима для успешных логинов) и сохраняем в БД. Если произошла ошибка валидации, в массив $errors сохраняем ошибки (они доступны через метод errors(), ну да вы помните). На всякий случай проверяем, сохранилась ли запись в БД, чтобы выдать соответствующую ошибку.

Как вы наверняка заметили, при успешном выполнении сценария идет редирект на метод profile(), в нем мы позже сделаем просмотр подробных данных, но сейчас достаточно и строки об успехе нашего предприятия. Если же произошла ошибка, необходимо не только отобразить ошибки, но и заполнить поля формы ранее введенными пользователем данными (кроме паролей конечно). Для этого используем переменную шаблона $postdata и метод as_array().

Чего-то не хватает…

Конечно, сразу у вас ничего хорошего не запустится, т.к. не созданы шаблоны. Итак, исходники в студию!

Файл application/views/auth/register.php:

<?php defined('SYSPATH') OR die('No direct access allowed.'); ?>
<form action='<?=url::base(FALSE)?>auth/register' id='login' method='post'>
<fieldset>
  <legend>Регистрация пользователя</legend>
  <div id='errors'><?foreach($errors as $key=>$val):?><p><?=$key.":".$val?></p><? endforeach?></div>
  <ol>
    <li><label for='email'>e-mail <em>*</em> </label><input type='text' name='email' id='email' size="30" maxlength="32" value="<?=isset($postdata['email']) ? $postdata['email'] : ''?>" /></li>
    <li><label for='email'>Повторите e-mail <em>*</em> </label><input type='text' name='email_confirm' id='email_confirm' size="30" maxlength="32" value="<?=isset($postdata['email_confirm']) ? $postdata['email_confirm'] : ''?>" /></li>
    <li><label for='username'>Логин <em>*</em> </label><input type='text' name='username' id='username' size="30" maxlength="32" value="<?=isset($postdata['username']) ? $postdata['username'] : ''?>" /></li>
    <li><label for='password'>Пароль <em>*</em> </label><input type='password' name='password' id='password' size="30" maxlength="50" /></li>
    <li><label for='password'>Повторите пароль <em>*</em> </label><input type='password' name='password_confirm' id='password_confirm' size="30" maxlength="50" /></li>
    <li><input type="submit" value="Зарегистрироваться" /></li>
  </ol>
</fieldset>
</form>

Файл application/views/index.php (он слегка изменился с прошлого раз):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title><?=$title?></title>
<link rel="stylesheet" href="<?=url::base(FALSE)?>css/index.css" type="text/css" media="screen" />
</head>
<body>
<div id='wrapper'>
    <div id='header'>
        <h1>Наш блог</h1>
        <p class='loginboard'><?=$login?></p>
    </div>
    <div id='page'>
    <div id='content'>
      <?=$content?>
    </div>
    <div id='sidebar'>
        <ul class='menu'>
            <?foreach ($menus as $menu): ?>
            <li><a href="<?=$menu['link']?>"><?=$menu['title']?></a></li>
            <?endforeach;?>
        </ul>
    </div>
    </div>
</div>
<div id='footer'>
Made in Russia, 2009
</div>
</body>
</html>

Ну и чтобы форма регистрации смотрелась веселее, добавим немного стилей в css/index.php:

form#login fieldset {
  margin-bottom: 10px;
}
form#login legend {
  padding: 0 2px;
  font-weight: bold;
}
form#login label {
  display: inline-block;
  font-size: 1.1em;
  vertical-align: top;
  width: 200px;
  color: #A52A2A;
}
form#login label em {
  color: red;
}
form#login ol {
  margin: 0;
  padding: 0;
}
form#login li {
  list-style: none;
  padding: 5px;
  margin: 0;
  border-bottom: 1px solid silver;
}

Теперь можно открыть http://localhost/auth/ и полюбоваться на форму регистрации. Хотя зачем любоваться, возьмем да зарегистрируемся!

PS. Прощаться не будем

Конечно, даже если все у вас получилось с первого раза, сам по себе результат не очевиден – в факте создания нового пользователя мы можем убедиться только вручную сделав выборку из БД. Поэтому-то я очень скоро напишу вторую часть статьи, в которой мы научимся входить на сайт, выходить и “не терять себя” при переходе с одной страницы на другую. До скорой встречи!

Update

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

А вот если вы запустите созданный нами ранее контроллер Blog_Controller (или даже просто страницу по умолчанию http://localhost, если вы перенастроили routing на этот контроллер), то увидите отладочной сообщение об отсутствующей переменной $login в шаблоне. Самый простой выход – создать эту переменную в конструкторе этого контроллера, а лучше – переходите-ка вы ко второй части.

Проблема

Не буду сильно вдаваться в подробности (они будут описаны в статье), просто скажу, что в модуле Auth поставляется модель Auth_User, у которой присутствует метод validate(). Он выполняет проверку введенных данных на соответствие следующим правилам (они описаны в теле модели и извне их не изменить):

	/**
	 * Validates and optionally saves a new user record from an array.
	 *
	 * @param  array    values to check
	 * @param  boolean  save the record when validation succeeds
	 * @return boolean
	 */
	public function validate(array & $array, $save = FALSE)
	{
	$array = Validation::factory($array)
		->pre_filter('trim')
		->add_rules('email', 'required', 'length[4,127]', 'valid::email')
		->add_rules('username', 'required', 'length[4,32]', 'chars[a-zA-Z0-9_.]', array($this, 'username_exists'))
		->add_rules('password', 'required', 'length[5,42]')
		->add_rules('password_confirm', 'matches[password]');

Если вы читали статью в справочнике об объекте Validation (нет?! так прочтите ), то все должно быть понятно. Сперва данные фильтруются (функция trim() удаляет пробелы слева и справа в строке), далее добавляются правила:

• Адрес электронной почты должен присутствовать (required), быть от 4 до 127 символов длиной (length[4,127]), ну и быть собственно корректным электронным адресом (valid::email)
• Имя пользователя должно присутствовать, длина 4-32 символа, состоять из латинских букв, цифр, знака подчеркивания и точки (chars[a-zA-Z0-9_.]), плюс дополнительная проверка методом username_exists модели Auth_User.
• Пароль должен присутствовать, длина от 5 до 42 символов.
• Подтверждение пароля должно соответствовать паролю (естественно, нет смысла делать проверку длины и т.д.)

И если проблем со стандартными правилами нет, то username_exists ведет себя странно – существующие логины пропускает, а незанятые не дает зарегистрировать. Смотрим исходники:

	/**
	 * Tests if a username exists in the database. This can be used as a
	 * Valdidation rule.
	 *
	 * @param   mixed    id to check
	 * @return  boolean
	 */
	public function username_exists($id)
	{
		return (bool) $this->db
			->where($this->unique_key($id), $id)
			->count_records($this->table_name);
	}

Ошибку видите? Считаю до десяти и даю подсказку – какой будет результат, если количество записей (count_records()) будет равно нулю? Вот и я о том же. В итоге пришлось немного порыскать на форуме Kohana и выяснилось, что проблема известна, и в будущих версиях (2.4 и 2.3.2) она будет исправлена. Сейчас же остается только вручную вносить изменения, чем и займемся.

Лекарство

Единственный видимый мне способ (кроме правки непосредственно исходного файла) – копирование скрипта Auth_User.php в application/models и уже там править под себя. Т.е. мы будем использовать преимущества каскадной файловой системы (сперва класс смотрится в application, и только потом в modules). Вот какие мы внесем поправки:

// файл application/models/Auth_User.php
// Строка 35. Вместо
     ->add_rules('username', 'required', 'length[4,32]', 'chars[a-zA-Z0-9_.]', array($this, 'username_exists'))
// пишем
     ->add_rules('username', 'required', 'length[4,32]', 'chars[a-zA-Z0-9_.]', array($this, 'username_available'))
 
// Строка 124. Заменяем метод username_exists на свой метод username_available:
	public function username_available($id)
	{
		return !$this->db
			->where($this->unique_key($id), $id)
			->count_records($this->table_name);
	}

Сохраняем, проверяем. Теперь все тип-топ.

Постскриптум

Подобные сырости встречаются, поэтому я и решил создать для них отдельную рубрику “Напильник”. До встречи!