CmsAuthentification

Материал из CmwCms
Перейти к: навигация, поиск

Аутентификация в CMS[править]

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


Для начала, определение. Аутентификация (подтверждение подлинности) — это проверка соответствия субъекта и того, за кого он пытается себя выдать, с помощью некой уникальной информации (отпечатки пальцев, цвет радужки, голос и т. д.), в простейшем случае — с помощью имени входа и пароля. (http://ru.wikipedia.org/wiki/Аутентификация) оризации: Авторизация — в информационных технологиях — предоставление определённых полномочий лицу или группе лиц на выполнение некоторых действий в системе обработки данных. Посредством авторизации устанавливаются и реализуются права доступа к ресурсам. (http://ru.wikipedia.org/wiki/Авторизация)

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

Существующий в протоколе HTTP метод авторизации малоприменим в работе по той простой причине, что в протоколе не описано процедуры прекращения сеанса, однако для различных автоматизированных запросов к ядру системы доступность такого механизма будет очень кстати. Для того, чтобы пользоваться им, небходим соответствующий модуль для apache, который будет проверять действительность предъявленной пары login/password в базе пользователей СMS.

Аутентификации через простую веб-форму и последующую установку cookie - наиболее распространенный вариант. К недостатку такого способа можно отнести незащищенность от cнифферов на фазе передачи пароля (вроде как ЖЖ использует криптование средствами js чтобы этого избежать). После первоначальной проверки пароля сервер устанавливает пользователю соответствующую cookie.

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

Несущественной вариацией варианта с cookie является добавление в адрес страницы кода сеанса.

Кроме аутентификации по логину/паролю актуален вариант аутентификации по диапазону ip-адресов.