Основные ошибки проектирования процесса авторизации

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

 

 

1) После авторизации показывать пользователю окно с перенаправлением

Стремитесь проектировать взаимодействие с пользователем в 1-Клик. Для программиста это не очевидно, но каждое дополнительное открытие не нужного промежуточного окна увеличивает время достижения результата на 100% от идеального показателя.

Многие известные системы страдают этим. Насколько я помню у всех форумов phpBB до сих пор после авторизации идёт страница «Подождите, вы будете перенаправлены, если ваш браузер не поддерживает редиректы нажмите…  блаблабла». Не стоит даже обсуждать случай, когда браузер пользователя действительно не поддерживает meta-перенаправления, потому что тогда время его взаимодействия на данном действие возрастёт на 1000%. Замечу что плохи именно meta, а не http редиректы (301,302).

Обычно ошибка заключается в том что программист реализует функцию проверки авторизации используя переменные $_COOKIE, а проводит авторизацию используя функцию setcookie(), которая устанавливает куксу, но не устанавливает переменную. Или же проверка авторизации запускается после авторизации на странице.

Решение: принудительно устанавливать переменную $_COOKIE, а вызов функции авторизации подвинуть выше проверки на авторизацию.

2) После авторизации показывать главную страницу, или страницу профиля пользователя

В 99% случаев это не та страница ради которой пользователь авторизовался на сайте. Как правило пользователь захотел прокомментировать статью, или скачать торрент, или совершить какое-либо другое действие на странице на которой он находился до этого.

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

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

Решение — использовать в этой функции http-переадресацию на страницу $_SERVER['HTTP_REFERER'], если она задана. Либо производить авторизацию на той же странице (т. е. на любой странице движка), используя в качестве action адреса формы авторизации — значение $_SERVER['REQUEST_URI'].

Замечу, что авторизация на отдельной странице /login/ и переадресация на нужную пользователю страницу, методом http-редиректа, является предпочтительной, т. к. в случае обновления страницы, браузер не спросит нужно ли посылать данные формы заново. Вы можете проверить это, войдя на сайт чтобы оставить комментарий к этой статье =).

3) При отсутствии авторизации перенаправлять на главную страницу

Это больше всего характерно для админ-панелей сайтов, и подобных закрытых систем. Очень часто, когда менеджер сайта заходит по ссылке /admin/items/edit_4999.html — он обнаруживает, что не авторизован на сайте. Адрес страницы часто бывает сложно запомнить, и система управления контентом должна приложить определённые усилия, чтобы менеджер никак не потерял этот адрес. Перенаправлять в данном случае не авторизовавшихся пользователей — не вежливо. Сайт который мы с коллегами улучшали сегодня — просто говорил о том что доступ запрещён, на нужной странице, и содержал ссылку на страницу с формой авторизации, что не многим лучше.

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

Решением для админ-панелей — является показ формы авторизации на странице требующей пароля. Так, чтобы пользователь попал куда надо в 1-клик.

4) Вызывать проверку авторизации в каждой функции

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

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

Решение — в одном месте будет гораздо проще отследить, какой функционал требует авторизации, а какой нет.

Заключение

Надеюсь статья поможет начинающим программистам сделать несколько улучшений их кода.

P. S. Кстати, слова «авторизироваться» в русском языке нет, правильно говорить «авторизоваться». Я считаю, что это эквивалентно словам «входить» и «войти». Правильно — «авторизовавшись», вместо «авторизировавшись».

P. P. S. Термин 1-клик можно увидеть в действие на сайте amazon.com, он был реализован Джеффом Безосом, основателем компании Amazon.com и его проэктировщиками. О проектировании подобных интерфейсов вы можете прочитать в книге Алана Купера «Психбольница в руках пациентов».