Вы находитесь здесь: Главная > Программирование > Аутентификация

Аутентификация

конверты для новорожденного . Поселок Красная поляна новый год в горах .

viktor■   Аутентификация заключается в проверке, действительно ли пользова­тель — тот. за кого себя выдает. Обычно для этого проверяется его пользова­тельское имя-псевдоним и прилагающийся к нему пароль.

■   Авторизация определяет, можно ли допустить пользователя к определенно­му ресурсу — при условии, что он успешно прошел процедуру аутентифика­ции. В ходе авторизации также определяется, что разрешено делать на сайте пользователю, не прошедшему аутентификацию. В нашем приложении под ресурсом надо понимать определенную веб-страницу или операцию — на­пример, операцию помещения в блог новой заметки.

В этой главе мы добавим в приложение средства аутентификации пользовате­лей с помощью компонента Zend_Auth из библиотеки Zend Framework. В числе этих средств — таблицы базы данных для хранения информации о пользователях. Затем с помощью компонента Zend Acl определим, каким пользователям предос­тавлять право доступа к тем или иным ресурсам. Кроме того, систему допусков нужно связать с классом Zend_Controller_Front.

Создание таблицы пользователей в базе данных

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

Доступ к нашему веб-приложению будут иметь три категории пользователей: гости (guest), зарегистрированные пользователи (member) и администраторы (administrator). Любой посетитель сайта автоматически квалифицируется как гость, пока не войдет на сайт с паролем как зарегистрированный пользователь. Чтобы отличать их от администраторов, в таблице users для каждого пользователя предусмотрен столбец role (роль). Этот столбец будет использоваться при реали­зации списков управления доступом с помощью компонента Zend Acl.

Примечание

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

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

■   user id — целое число, используемое для внутреннего представления поль­зователя, его идентификационный номер.

■   username — уникальный буквенный идентификатор пользователя, исполь­зуемый для входа на сайт. Это имя будет публичным — оно отображается в записях блога и других видах общедоступного контента сайта вместо на­стоящих имен, которые пользователи обычно скрывают.

■   password— строка символов, по которой выполняется аутентификация пользователя. Пароли будут храниться в хешированном виде с использова­нием функции md5 (). Это означает, что забытый пароль нельзя извлечь из базы и восстановить, а можно только заменить новым. Весь код, необходи­мый для этого, будет реализован.

■   user type — строка, обозначающая классификацию пользователя по сис­теме типов или категорий (это будет либо admin, т.е. администратор, либо member, т.е. зарегистрированный пользователь; в будущем вы сможете легко добавить новые типы на основе полученных знаний).

■   ts_created — время создания учетной записи.

■   ts_last_login— время последнего входа пользователя на сайт под своим именем. Это поле может иметь значение null, поскольку только что зареги­стрированный пользователь еще ни разу не входил на сайт.

В листинге 3.1 приведены команды SQL, необходимые для создания таблицы users в базе данных MySQL. Все SQL-определения структуры таблицы хранятся в файле schema-mysql. sql, помещенном в корневой каталог приложения. Если вместо MySQL используется PostgreSQL, соответствующая структура будет нахо­диться в файле schema-pgsql. sql.

Примечание

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

Листинг 3.1. Код SQL для создания таблицы пользователей в базе данных MySQL (файл schema-mysql. sql)

create table users        (

user_id                serial                      not null,

username             varchar (255)           not null,

password             varchar (32)             not null,

user_type             varchar (20)             not null,

 

ts_created              datetime               .not null,

ts_last_login datetime,

primary key (user_id), unique (username) ) type = InnoDB;

Тип столбца (поля) user_id определен как serial, что эквивалентно bigint un­signed not null auto_increment. Лично я предпочитаю serial — это короче, быстрее и совместимо с PostgreSQL.

Поле username может иметь до 255 символов в длину, хотя в нашем коде на дли­ну будут наложены дополнительные ограничения. Пароль будет храниться в за­шифрованном по методу MD5 виде, поэтому полю пароля достаточно иметь в длину 32 символа.

Далее идет поле user_type. Длина этого поля не играет особой роли; правда, на­звание любого нового типа (категории), который вы захотите добавить, должно иметь в длину не более 20 символов (это внутреннее, невидимое пользователям имя, поэтому оно не обязано быть очень информативным). Это поле используется при проверках прав доступа.

Наконец, имеются два поля с временными метками. Собственно говоря, в MySQL имеется тип данных под названием timestamp, но я решил вместо него использо­вать тип datetime, поскольку СУБД автоматически обновляет столбцы, данные в которых имеют тип timestamp. В PostgreSQL вместо этого типа нужно использо­вать timestamptz (см. файл schema-pgsql. sql с определением структуры табли­цы). Далее в разделе «Временные метки» имеется более подробная информация о работе с временем в РНР.

Совет

В листинге 3.1 при создании таблицы используется тип InnoDB, благодаря чему есть возможность вы­полнять транзакции SQL и разрешены реляционные связи по внешним ключам. По умолчанию использо­вался бы тип myisam, в котором этих возможностей нет.

Теперь необходимо создать в базе данных эту таблицу. Есть два способа сделать это. Во-первых, можно перенаправить весь файл schema-mysql. sql в базу данных следующей командой:

#   mysql -u phpweb20 -р phpweb20 < schema-mysql.sql

После ввода этой команды вам будет предложено ввести пароль. База данных будет создана целиком с нуля.

Вместо этого можно подключиться напрямую к базе данных, скопировать и вста­вить структуру таблицы следующей командой:

#   mysql -u phpweb20 -р phpweb20

Поскольку по мере работы над приложением мы будем дорабатывать базу дан­ных, рекомендую второй способ, чтобы просто добавлять новые таблицы по мере надобности.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • Twitter
  • RSS

Оставить комментарий

This blog is kept spam free by WP-SpamFree.