Доступ к области администрирования.

Касты администраторов.

Из рассказа про иерархию администраторов уже становится ясно, что просто не будет. Поэтому договоримся, что в дальнейшем под полноценным администратором мы понимаем учётную запись "уровня бога", с именем master. То есть этому администратору дозволено всё и в полном объёме.

Прочие администраторы будут в чём-то ущемлены, их ранг ниже.

Адрес для авторизации.

/admin/login.htm относительно корня скрипта.
Расширение - то, которое Вы назначите в настройках.
Сам файл дозволяется переименовать.

Методов авторизации в админке целых четыре разных:

1) Вход по логину и паролю.

Самый распространённый метод. Активируется в файле настроек так:

   'login'     => array(
      
'method' => 'passw'# passw|crypt|token|key

Или так (оба варианта равнозначны):

   'login'     => array(
      
'method' => 'login'# passw|crypt|token|key

Выглядит вполне обыденно:

Доступ к разделу Администратора сайта:

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

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

Существует также масса зловредов, без проблем ворующих такие пароли как из браузеров, так и ФТП клиентов - с последними почти каждый бывалый вебмастер сталкивался лично.

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

Может использоваться только с двухфакторной аутентификацией.

2) Авторизация плавающим кодом.

Визуально схоже с предыдущим методом, однако авторизационные данные (логин и пароль) передаются по каналам связи не как есть, а после их предварительного хэширования. "Соль" для хэша динамически меняется каждую секунду. Соответственно, при неизменных логине с паролем на сервер уходит каждый раз новый код. Это и называется плавающим кодом.

Метод авторизации плавающим кодом активируется в файле настроек так:

   'login'     => array(
      
'method' => 'crypt'# passw|crypt|token|key

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

Доступ к разделу Администратора сайта:

Логин с паролем захэшируются в плавающий код, и автоматически отправятся на сервер (для наглядности поле пароля тут переключается в режим отображения символов).

Все недостатки авторизации по логину и паролю сохраняются. Но сами авторизационные данные теперь прикрыты криптографией, и теряют актуальность менее чем через минуту. Это, конечно, ещё не SSL, но уже не передача данных в голом виде.

Тем не менее, двухфакторная аутентификация должна использоваться.

3) Вход по токену.

На уровне файла настроек активируется совершенно ожидаемо:

   'login'     => array(
      
'method' => 'token'# passw|crypt|token|key

Форма авторизации внешне почти такая же:

Доступ к разделу Администратора сайта:

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

Собственно токен представляет собой простой HTML файл с JavaScript внутри, и генерируется для каждого администратора персонально.

Как он выглядит и работает, не секрет.
Можно с формой токена пообщаться:

Генератор токенов администратора User

Преимущества перед логином и паролем тоже понятны - всё, что запомнил браузер, совершенно не важно, ибо одноразовое. Записывать на стикер и приклеивать к монитору (как это практикуется) тоже нечего.

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

4) Вход по Ключу.

Ключом может служить любой файл на компьютере или сменном носителе, объёмом до ста килобайт. Не важно, что это - текстовый документ, изображение любого формата, архив, или даже системный файл компьютера. Главное, чтобы этот файл оставался неизменным. А располагаться в файловой системе компьютера он может где угодно.

Включается режим доступа к админке по Ключу в файле настроек так:

   'login'     => array(
      
'method' => 'key',   # passw|crypt|token|key

Форма авторизации выглядит нетривиально:

Авторизация в админке по ключу.

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

Каждый из Администраторов имеет собственный файл-ключ.
При этом сами ключи на сервере не остаются.

Знакомство Nano-CMS с Ключом Администратора.

Естественно, каждый из Администраторов должен сначала познакомить Нану со своим Ключом доступа, после чего он и станет эталоном для сверки. Делается это довольно просто:

  1. Вместо адреса /admin/login.htm относительно корня скрипта Администратор обращается к чуть модифицированному адресу /admin/login_xxx.htm

    На место знаков xxx в адрес подставляется имя Администратора.

    Обратите внимание, это не его логин, пароль, либо что-то ещё, а именно имя. На примере пункта 1 из инструкции это будет либо master, либо user.

  2. Форму загрузки следует натравить на файл весом до 100 килобайт.
    Обратите на это внимание.

    Форма загрузки отвергает выбранный файл?

    Либо его объём превышает указанный выше лимит, либо в пути до файла имеются символы, не перечисленные в качестве разрешённых вот в этой строке файла авторизации ./data/content/admin/login.php:

     '===pattern===' => '[a-zA-Z0-9:\._ а-яA-Я+-(ёЁ)=]{3,256}',

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

    Если у Вас именно такой антивирус (AVG, например), держите ключ в директории, в которой файлы не будут проверяться по пять минут.

    Скормленный Нане, файл становится Ключом доступа для данного Администратора, а сам Администратор тем самым заодно авторизуется. В дальнейшем доступ к админке по Ключу проистекает по стандартному адресу /admin/login.htm относительно корня скрипта.

    О судьбе нестандартной страницы авторизации:

    После того, как Ключ для данного Администратора задан и принят Nano-CMS в качестве эталона, модифицированный адрес доступа /admin/login_xxx.htm не выполняет никаких действий ни под авторизацией, ни без авторизации. То есть Ключ задаётся однократно, и в дальнейшем не может быть изменён.

    Если всё же возникла необходимость смены ключа доступа:

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

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

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

Безопасность.

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

  'login'    => array(
     
'timer' => 24,       # Максимальное время авторизации, в часах.
     
'brutt' => 3,        # max. число неудач при авторизации.

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

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

Можете эту процедуру изучить - Login