Сегoдня мы рассмотрим эксплуатацию критической 1day-уязвимости в популярной CMS Joomla, которая прогремела на просторах интернета в конце октября. Речь пойдет об уязвимостях с номерами CVE-2016-8869 , CVE-2016-8870 и CVE-2016-9081 . Все три происходят из одного кусочка кода, который пять долгих лет томился в недрах фреймворка в ожидании своего часа, чтобы затем вырваться на свободу и принести с собой хаос, взломанные сайты и слезы ни в чем не повинных пользователей этой Joomla. Лишь самые доблестные и смелые разработчики, чьи глаза красны от света мониторов, а клавиатуры завалены хлебными крошками, смогли бросить вызов разбушевавшейся нечисти и возложить ее голову на алтарь фиксов.

WARNING

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

С чего все началось

6 октября 2016 года Дэмис Пальма (Demis Palma) создал топик на Stack Exchange , в котором поинтересовался: а почему, собственно, в Joomla версии 3.6 существуют два метода регистрации пользователей с одинаковым названием register() ? Первый находится в контроллере UsersControllerRegistration , а второй - в UsersControllerUser . Дэмис хотел узнать, используется ли где-то метод UsersControllerUser::register() , или это лишь эволюционный анахронизм, оставшийся от старой логики. Его беспокоил тот факт, что, даже если этот метод не используется никаким представлением, он может быть вызван при помощи сформированного запроса. На что получил ответ от девелопера под ником itoctopus, подтвердившего: проблема действительно существует. И направил отчет разработчикам Joomla.

Далее события развивались самым стремительным образом. 18 октября разработчики Joomla принимают репорт Дэмиса, который к тому времени набросал PoC, позволяющий регистрировать пользователя. Он опубликовал заметку на своем сайте , где в общих чертах рассказал о найденной проблеме и мыслях по этому поводу. В этот же день выходит новая версия Joomla 3.6.3, которая все еще содержит уязвимый код.

После этого Давиде Тампеллини (Davide Tampellini) раскручивает баг до состояния регистрации не простого пользователя, а администратора. И уже 21 октября команде безопасности Joomla прилетает новый кейс. В нем речь уже идет о повышении привилегий . В этот же день на сайте Joomla появляется анонс о том, что во вторник, 25 октября, будет выпущена очередная версия с порядковым номером 3.6.3, которая исправляет критическую уязвимость в ядре системы.

25 октября Joomla Security Strike Team находит последнюю проблему, которую создает обнаруженный Дэмисом кусок кода. Затем в главную ветку официального репозитория Joomla пушится коммит от 21 октября с неприметным названием Prepare 3.6.4 Stable Release , который фиксит злосчастный баг.

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

27 октября исследователь Гарри Робертс (Harry Roberts) выкладывает в репозиторий Xiphos Research готовый эксплоит , который может загружать PHP-файл на сервер с уязвимой CMS.

Детали

Что ж, с предысторией покончено, переходим к самому интересному - разбору уязвимости. В качестве подопытной версии я установил Joomla 3.6.3, поэтому все номера строк будут актуальны именно для этой версии. А все пути до файлов, которые ты увидишь далее, будут указываться относительно корня установленной CMS.

Благодаря находке Дэмиса Пальмы мы знаем, что есть два метода, которые выполняют регистрацию пользователя в системе. Первый используется CMS и находится в файле /components/com_users/controllers/registration.php:108 . Второй (тот, что нам и нужно будет вызвать), обитает в /components/com_users/controllers/user.php:293 . Посмотрим на него поближе.

286: /** 287: * Method to register a user. 288: * 289: * @return boolean 290: * 291: * @since 1.6 292: */ 293: public function register() 294: { 295: JSession::checkToken("post") or jexit(JText::_("JINVALID_TOKEN")); ... 300: // Get the form data. 301: $data = $this->input->post->get("user", array(), "array"); ... 315: $return = $model->validate($form, $data); 316: 317: // Check for errors. 318: if ($return === false) 319: { ... 345: // Finish the registration. 346: $return = $model->register($data);

Здесь я оставил только интересные строки. Полную версию уязвимого метода можно посмотреть в репозитории Joomla.

Разберемся, что происходит при обычной регистрации пользователя: какие данные отправляются и как они обрабатываются. Если регистрация пользователей включена в настройках, то форму можно найти по адресу http://joomla.local/index.php/component/users/?view=registration .

Легитимный запрос на регистрацию пользователя выглядит как на следующем скриншоте.

За работу с пользователями отвечает компонент com_users . Обрати внимание на параметр task в запросе. Он имеет формат $controller.$method . Посмотрим на структуру файлов.

Имена скриптов в папке controllers соответствуют названиям вызываемых контроллеров. Так как в нашем запросе сейчас $controller = "registration" , то вызовется файл registration.php и его метод register() .

Внимание, вопрос: как передать обработку регистрации в уязвимое место в коде? Ты наверняка уже догадался. Имена уязвимого и настоящего методов совпадают (register), поэтому нам достаточно поменять название вызываемого контроллера. А где у нас находится уязвимый контроллер? Правильно, в файле user.php . Получается $controller = "user" . Собираем все вместе и получаем task = user.register . Теперь запрос на регистрацию обрабатывается нужным нам методом.

Второе, что нам нужно сделать, - это отправить данные в правильном формате. Тут все просто. Легитимный register() ждет от нас массив под названием jform , в котором мы передаем данные для регистрации - имя, логин, пароль, почту (см. скриншот с запросом).

• /components/com_users/controllers/registration.php: 124: // Get the user data. 125: $requestData = $this->input->post->get("jform", array(), "array");

Наш подопечный получает эти данные из массива с именем user .

• /components/com_users/controllers/user.php: 301: // Get the form data. 302: $data = $this->input->post->get("user", array(), "array");

Поэтому меняем в запросе имена всех параметров с jfrom на user .

Третий наш шаг - это нахождение валидного токена CSRF, так как без него никакой регистрации не будет.

• /components/com_users/controllers/user.php: 296: JSession::checkToken("post") or jexit(JText::_("JINVALID_TOKEN"));

Он выглядит как хеш MD5, а взять его можно, например, из формы авторизации на сайте /index.php/component/users/?view=login .

Теперь можно создавать пользователей через нужный метод. Если все получилось, то поздравляю - ты только что проэксплуатировал уязвимость CVE-2016-8870 «отсутствующая проверка разрешений на регистрацию новых пользователей».

Вот как она выглядит в «рабочем» методе register() из контроллера UsersControllerRegistration:

• /components/com_users/controllers/registration.php: 113: // If registration is disabled - Redirect to login page. 114: if (JComponentHelper::getParams("com_users")->get("allowUserRegistration") == 0) 115: { 116: $this->setRedirect(JRoute::_("index.php?option=com_users&view=login", false)); 117: 118: return false; 119: }

А так в уязвимом:

• /components/com_users/controllers/user.php:

Ага, никак.

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

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!

Из этого туториала вы узнаете, как разрешить регистрацию пользователей на сайте Joomla 3.x и управлять ею.

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

Разрешите общую регистрацию. Откройте панель управления Joomla и перейдите в раздел Система (System) > Общие настройки (Global Configuration) > Менеджер пользователей (Users Manager) > Компонент (Component) > Разрешить регистрацию пользователей (Allow User Registration) . Установите значение Да (‘YES’) и сохраните изменения:

Опубликуйте модуль Входа на сайт (Login). Перейдите в раздел Расширения (Extensions) > Менеджер модулей (Module manager) > Форма входа на сайт (Login Form ) и нажмите кнопку «Включить»(‘Enable’) для того, чтобы активировать модуль.

Опубликуйте кнопку входа на сайт. Перейдите в раздел Меню (Menus) > Меню пользователей (User Menu) > Вход (Login). Включите ее.

Добавьте пункт меню для регистрации пользователей. Перейдите в раздел Меню (Menus) > Меню пользователей (User Menu) > Создать (Add New) . Укажите заголовок новой кнопки меню. Перейдите в Тип пункта меню (Menu Item Type) > Выбрать (Select) > Менеджер пользователей (Users Manager) > Форма регистрации (Registration Form) . Во вкладке «Оформление шаблона»(‘Template Style’) выберите theme####-Default и сохраните изменения:

Теперь обновите сайт, кнопки входа на сайт (Login) и регистрации (Registration) успешно добавлены.

Срабатывает сразу после того, как новый пользователь был зарегистрирован на сайте. После того, как данные пользователя были добавлены в базу данных.

Хук получает в качестве параметра ID пользователя.

На момент срабатывания этого хука, все метаданные уже добавлены в БД. Пароль уже зашифрован.

Этот хук можно использовать для добавления дополнительных метаданных переданных в форме регистрации нового пользователя.

Для добавления или обновления метаданных пользователя, также можно использовать хук insert_user_meta . См. пример ниже или код функции wp_insert_user()

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

add_action("user_register", "____action_function_name"); function ____action_function_name($user_id) { // Действие... } $user_id(число) ID зарегистрированного пользователя.

Примеры

#1 Добавим дополнительные данные пользователя при регистрации

Этот пример показывает как добавить значение поля user_sex , которое передается в $_POST данных из формы регистрации.

Имейте ввиду, что проверка обновляемых данных не должна производиться в момент этого хука - уже слишком поздно, пользователь уже добавлен! Проверку данных нужно делать во время хука registration_errors , хук user_register не сработает если проверка не будет пройдена...

// предварительная проверка поля add_filter("registration_errors", "my_validate_user_data"); function my_validate_user_data($errors){ if(empty($_POST["user_sex"])) $errors->add("empty_user_sex", "Пол обязательно должен быть указан!"); elseif(! in_array($_POST["user_sex"], array("male","female"))) $errors->add("invalid_user_sex", "Пол указан неверно!"); return $errors; } // обновление метаданных пользователя add_action("user_register", "my_user_registration"); function my_user_registration($user_id) { // $_POST["user_sex"] проверена заранее... update_user_meta($user_id, "user_sex", $_POST["user_sex"]); }

#2 Обновление метаданных пользователя при регистрации

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

Этот пример полностью заменяет хук user_register из предыдущего примера. Проверку на ошибки берем из пред. примера.

// $meta = apply_filters("insert_user_meta", $meta, $user, $update); add_filter("insert_user_meta", "my_user_registration_meta", 10, 3); function my_user_registration_meta($meta, $user, $update) { // выходим если это не регистрация юзера if($update) return $meta; $meta["user_sex"] = $_POST["user_sex"]; // $_POST["user_sex"] проверена заранее... return $meta; }

Список изменений

С версии 1.5.0

Введена.

Где вызывается хук

Где используется хук (в ядре WP)

wp-admin/includes/admin-filters.php 92 add_action("user_register", array("WP_Internal_Pointers", "dismiss_pointers_for_new_users"));

Урок, в котором познакомимся с дополнением Login. Данное дополнение предназначено для реализации на сайте всего что может понадобиться для работы с пользователями во front-end. Оно включает в себя элементы для реализации регистрации, подтверждения регистрации, восстановления и изменения пароля, авторизации, личного кабинета и многих других функций.

Установка приложения Login

Открываем страницу "Управление пакетами" (Приложения -> Установщик). Выполняем загрузку и установку компонента Login.

Создание группы пользователей и ресурсов "Users"

Открываем страницу "Контроль доступа" (Шестерёнка -> Контроль доступа). Нажимаем на кнопку "Новая группа пользователей".

В диалоговом окне "Создать группу пользователей" заполняем следующие поля:

• Имя: Users;
• Описание: Зарегистрированные пользователи;
• Создать параллельную группу ресурсов: Да;
• Политики бэкэнда: (нет политики).

Проверяем, появилась ли новая группа ресурсов "Users". Эта группа ресурсов была создана во время создания группы пользователей "Users" (включенная опция "Создать параллельную группу ресурсов"). Группа ресурсов "Users" необходима для помещения в неё ресурсов, доступ к которым будут иметь пользователи, расположенные в группе "Users". Это будут ресурсы "Личный кабинет", "Смена пароля" и "Редактирование данных". Анонимные пользователи не смогут получить доступ к этим ресурсам.

Настраиваем права группы пользователей "Users". Для этого на странице "Контроль доступа" нажимаем правой кнопкой мыши на группу "Users" и выберем пункт "Редактировать группу пользователей".

На странице "Группа пользователя: Users" нажимаем правой кнопкой мыши на поле "web" и выбираем пункт "Редактировать доступ к контексту".

В диалоговом окне "Доступ групп пользователей к контексту" устанавливаем политику доступа на значение "Load, List and View" и нажимаем на кнопку "Сохранить".

Создание страниц (ресурсов) для Login. Настройка доступа к этим страницам

Создадим следующие страницы (ресурсы):

• Регистрация (28) и Подтверждение регистрации (31);
• Авторизация (29) и Восстановление пароля (32);
• Личный кабинет (30), Изменение пароля (33) и Редактирование данных (34).

Настроим доступ к страницам "Личный кабинет", "Изменение пароля", "Редактирование данных". Они должны быть доступны только зарегистрированным пользователям (Users).

Откроем страницу "Группы ресурсов" (Сайт->Группы ресурсов) и перенесём из правого дерева в группу «Users» вышеперечисленные ресурсы.

Кроме этого, группе пользователей (аноним) необходимо установить доступ "Load only". Это необходимо сделать для того чтобы они могли загружать страницы из группых ресурсов Users, проверять права доступа и получать ошибку 403 "Доступ запрещен". Если не дать (аноним) Load only, то для них эти страницы не будут существовать, и они получат ошибку 404 "Не найдено".

Порядок действий: Шестерёнка -> Контроль Доступа -> (аноним) -> Редактировать группу пользователей (правой кнопкой мыши) -> Доступ к группам ресурсов -> Добавить группу ресурсов.

В диалогово окне "Добавить группу ресурсов":

• Группа ресурсов: Users;
• Контекст: website (web);
• Минимальная роль: member (9999);
• Политика доступа: Load only.

Последнее что необходимо ещё сделать, это указать в качестве страницы ошибки 403 "Доступ запрещён" ресурс "Авторизация" (id=29). Осуществляется это в настройках системы с помощью параметра unauthorized_page. Теперь если анонимный пользователь захочет попасть на закрытые страницы, ему выведится страница "Авторизация".

Страница (ресурс) "Регистрация"

Страница "Регистрация" будет выполнять следующие действия:

• выводить пользователю регистрационную форму;
• обрабатывать отправленную пользователем форму (данные) на сервере с помощью сниппета Register.

Обработку формы сниппетом Register настроим так, чтобы он выполнял следующее:

1. Переходил к обработке регистрационной формы только в том случае, если она была отправлена с помощью кнопки, у которой значение атрибута name равно submitbtn .
2. Выполнял проверку (валидацию) полей формы на соответствие указанным требованиям. При обнаружении ошибок, выводил их в соотвествующие места ([[!+reg.error.имяПоля]]) формы.
3. Если форма, заполненная пользователем, ошибок не имеет (прошла валидацию):
   • отображал сообщение об успехе;
   • отправлял пользователю email, в котором содержалась бы сообщение и ссылка. Данное действие необходимо для того, чтобы пользователь подтвердил email, т.е. активировал с помощью неё (ссылки) свою учётную запись.

Содержимое ресурса "Регистрация" (форма и сниппет Register):

[[!Register? &submitVar=`submitbtn` &activation=`1` &activationEmailSubject=`Подтверждение регистрации` &activationResourceId=`31` &successMsg=`

Спасибо за регистрацию. На вашу электронную почту [[!+reg.email]] отправлено письмо, содержащее ссылку, необходимую для активацию аккаунта. Перейдите по этой ссылке, чтобы завершить процедуру регистрации.

` &usergroups=`Users` &usernameField=`email` &passwordField=`passwd` &validate=`nospam:blank, passwd:required:minLength=^8^, passwdAgain:passwdAgain=^passwd^, fullname:required, email:required:email` &placeholderPrefix=`reg.` ]]

Описание используемых параметров сниппета Register:

Имя параметра	Описание
submitVar	Ключ, значение которого проверяется перед тем как сниппет Register начнёт обрабатывать форму. Если в качестве значения этого параметра указать пустую строку или false , то сниппет Register будет обрабатывать форму при получении любого Post запроса.
activation	Определяет стоит ли подтверждать email, указанный в регистрационной форме, или нет. Т.е. пользователь не будет активированным до тех пор, пока он не подтвердит свой email. Значение: 1 (да, необходимо).
activationEmailSubject	Тема письма, в котором приходит ссылка для активирования учётной записи.
activationEmailTpl	Шаблон письма, содержащий информацию и ссылку для активирования учётной записи. Будем использовать шаблон по умолчаию: lgnActivateEmailTpl.
activationResourceId	Идентификатор ресурса, в котором находится сниппет с помощью которого осуществляется активирование учётной записи пользователя. Значение: 31 (id ресурса "Подтверждение регистрации").
successMsg	Отображает указанное сообщение после успешной отправки регистрационной формы. Этот параметр работает тогда, когда не используется параметр submittedResourceId.
submittedResourceId	Перенаправляет пользователя на указанный ресурс после успешной отправки регистрационной формы.
usergroups	Список (через запятую) названий групп пользователей или идентификаторов этих групп, в которые необходимо добавить только что зарегистрированного пользователя. Значение: Users.
usernameField	Имя поля формы, содержащее в качестве значения имя пользователя. Значение: email.
passwordField	Имя поля формы, содержащее пароль пользователя. Значение: passwd.
validate	Список (через запятую) полей для валидации (проверки). Указывается так: имя:валидатор (например, username: required , email:required). Валидаторы можно соединять. Например, email:email:required .
placeholderPrefix	Префикс для плейсхолдеров. Например, значения плейсхолдеров для поля email с учётом префикса reg. : [[!+reg.email]] (значения поля), [[!+reg.error.email]] (значение ошибки).

Как работает активация аккаунта

Происходит это так: после успешной валидации формы, сниппет Register создаёт объект modUser и устанавливает полю active значение 0. Далее он отправляет письмо пользователю по указанному в регистрационной форме email. Данное письмо содержит URL (ссылку для активации). Как только пользователь перейдёт по этому URL, сниппет ConfirmRegister изменит значение поля active на 1. Теперь пользователь сможет авторизироваться на сайте, т.е. войти под своей учётной записью.

Ресурс "Подтверждение регистрации"

Страница "Подтверждение регистрации" предназначена для активирования аккаунта пользователя. Активирование выполняет сниппет ConfirmRegister на основании URL. Принцип работы его заключается в том, чтобы изменить значение поля active пользователя на 1. После этого пользователь может авторизоваться на сайте, т.е. войти под своей учётной записью.

Содержимое ресурса "Подтверждение регистрации" (сниппет ConfirmRegister):

[[!ConfirmRegister? &authenticate=`1` &redirectTo=`4` &errorPage=`4` ]]

Описание используемых параметров сниппета ConfirmRegister.

Ранее были внесены изменения в файлы.

копируем из

components/com_users/views/registration/tmpl/ в
templates/protostar/html/com_users/registration/ файлы

default.php и default.xml и меняем им названия, к примеру на approval.php и approval.xml

approval.php

// здесь большое количество кода // .....

approval.xml

AGE_CHECKBOX_DESCRIPTION_HIDE AGE_CHECKBOX_DESCRIPTION_SHOW

Добавлены языковые замещения

language/overrides/en-GB.override.ini

MY_NEW_REGISTRATION="Registration form with additional fields" TERMS_OF_SERVICE="Terms of service" AGREE="I agree to the terms of use" AGE="I am at least 18 years old"

language/overrides/ru-RU.override.ini

MY_NEW_REGISTRATION="Регистрационная форма с дополнительными параметрами" TERMS_OF_SERVICE="Условия обслуживания" AGREE="Я согласен с условиями обслуживания" AGE="Мне уже есть 18 лет"

administrator/language/overrides/en-GB.override.ini

MY_NEW_REGISTRATION_TITLE="Registration form with additional fields" SHOW_AGE_CHECKBOX="Show Age Checkbox" SHOW_AGE_CHECKBOX_DESCRIPTION="Show or hide the age checkbox" AGE_CHECKBOX_DESCRIPTION_HIDE="Hide" AGE_CHECKBOX_DESCRIPTION_SHOW="Show"

administrator/language/overrides/ru-RU.override.ini

MY_NEW_REGISTRATION_TITLE="Регистрационная форма с дополнительными параметрами" SHOW_AGE_CHECKBOX="Показывать подтверждение
возраста при регистрации" SHOW_AGE_CHECKBOX_DESCRIPTION="Показывать / скрывать подтверждение возраста при регистрации" AGE_CHECKBOX_DESCRIPTION_HIDE="Скрыть" AGE_CHECKBOX_DESCRIPTION_SHOW="Показать"

Для отправки в суперглобальный массив переменных $_REQUEST методом POST значений полей формы необходимо, чтобы у каждого поля был уникальный атрибут name . Дополним поля флажков данным атрибутом в файле approval.php

params->get("show_age_checkbox")):?>

Теперь перейдем собственно к созданию самого плагина.

Назовем его myregistration . Создадим для него папку plugins/user/myregistration , в ней файлы myregistration.php и myregistration.xml . Не забываем про заглушку index.html

myregistration.xml

plg_user_myregistration March 2012 admin//dog//joomla.org www.joomla.org 2.5.0 PLG_USER_MYREGISTRATION_XML_DESCRIPTION myregistration.php index.html language

myregistration.php

isSite()){ return true; } // загружаем файл языковой поддержки $this->loadLanguauge(); $result = true; // проверить, установлен ли флажок согласия с условиями обслуживания if (!JRequest::getBool("tos_agree")){ JError::raiseWarning(1000, JText::_("PLG_USER_MYREGISTRATION_TOS_AGREE_REQUIRED")); $result = false; } // проверить установку флажка на подтверждение достижения 18 лет if (!JRequest::getBool("old_enough")) { JError::raiseWarning(1000, JText::_("PLG_USER_MYREGISTRATION_OLD_ENOUGH_REQUIRED")); $result = false; } return $result; } }

Имя класса указываем в соответствии с принятыми обозначениями

plgUserMyRegistration

plg (подключаемый плагин), User (пользовательский тип подключаемого плагина), MyRegistration (название плагина). Этот класс расширяет класс JPlugin .

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

JRequest::getBool() вызывается для получения элемента ввода tos_agree или old_enough из суперглобальной переменной $_REQUEST языка PHP. Возвращает false или true .

JError::raiseWarning() - вывод ошибки. В качестве аргументов указываются: код ошибки и текст ошибки. В данном случае код не используется и может быть любым, а текст выводим из файла языковой поддержки плагина.

Файлы языковой поддержки

Предпочтительно создавать их в папке с плагином.Русскоязычные должны быть в кодировке UTF-8 без BOM - иначе система их не подхватит.

Первые предназначены для всех переменных, которые используются на фронте и для вывода настроек самого плагина
plugins\user\myregistration\language\en-Gb\en-Gb.plg_user_myregistration.ini
plugins\user\myregistration\language\ru-RU\ru-RU.plg_user_myregistration.ini

Вторые используются для вывода названия плагина в менеджере плагинов и вывода сообщения после установки расширения
plugins\user\myregistration\language\en-Gb\en-Gb.plg_user_myregistration.sys.ini
plugins\user\myregistration\language\ru-RU\ru-RU.plg_user_myregistration.sys.ini

en-Gb.plg_user_myregistration.ini

PLG_USER_MYREGISTRATION_TOS_AGREE_REQUIRED="You must agree to the terms of service" PLG_USER_MYREGISTRATION_OLD_ENOUGH_REQUIRED="You must be at least 18 years old"

en-Gb.plg_user_myregistration.sys.ini

PLG_USER_MYREGISTRATION="User - My Registration" PLG_USER_MYREGISTRATION_XML_DESCRIPTION="Check that the Terms and Age boxes have been checked"

ru-RU.plg_user_myregistration.ini

PLG_USER_MYREGISTRATION_TOS_AGREE_REQUIRED="Вы должны согласиться с условиями обслуживания" PLG_USER_MYREGISTRATION_OLD_ENOUGH_REQUIRED="Вам должно быть не менее 18 лет"

ru-RU.plg_user_myregistration.sys.ini

PLG_USER_MYREGISTRATION="Юзер - Моя регистрация" PLG_USER_MYREGISTRATION_XML_DESCRIPTION="Проверка на согласие с условиями обслуживания и достижения пользователем возраста 18 лет"

Полностью автономная версия плагина.

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

Имя нового плагина myregistrationall. Состоит:

forms/form.xml
language/en-Gb/en-Gb.plg_user_myregistrationall.ini
language/en-Gb/en-Gb.plg_user_myregistrationall.sys.ini
language/ru-RU/ru-RU.plg_user_myregistrationall.ini
language/ru-RU/ru-RU.plg_user_myregistrationall.sys.ini
myregistrationall.php
myregistrationall.xml

Основной myregistrationall .xml файл плагина. В разделе конфигурации установлены поля для отображения в настройках плагина

plg_user_myregistrationall Mark Dexter and Louis Landry feat Taatshi March 2012 (C) 2012 Mark Dexter and Louis Landry GNU General Public License version 2 or later; See License.txt admin//dog//joomla.org www.joomla.org 2.5.0 PLG_USER_MYREGISTRATIONALL_XML_DESCRIPTION myregistrationall.php index.html language forms

JHIDE JSHOW

form.xml

myregistrationall.php

getName()!="com_users.registration") { return; } // Загрузить файл языковой поддержки $this->loadLanguage(); // Загрузить xml-файл в форму регистрации пользователя - обратить внимаение - вокруг FILE идет ДВОЙНОЕ ПОДЧЕРКИВАНИЕ $form->loadFile(dirname(__FILE__)."/forms/form.xml"); // Проверка установки параметра показа чекбокса для проверки возраста в настройках плагина if (!$this->params->get("show_age_checkbox", "1")) { $form->removeField("old_enough"); // Если мы захотим сделать поле подтверждения возраста необязательным, достаточно будет добавть строку: // $form->setFieldAttribute("old_enough", "requried", "false"); } } }

en-Gb.plg_user_myregistrationall.ini

PLG_USER_MYREGISTRATIONALL_TERMS_OF_SERVICE="Added Fields for Terms of Service Agreement" PLG_USER_MYREGISTRATIONALL_AGREE="I agree to the terms" PLG_USER_MYREGISTRATIONALL_AGE="I am at least 18 years old" PLG_USER_MYREGISTRATIONALL_SHOW_AGE="Show Age Checkbox" PLG_USER_MYREGISTRATIONALL_SHOW_AGE_DESC="Whether to Hide or Show the Show Age Check box. If it is shown, it will be required."

ru-RU.plg_user_myregistrationall.ini

PLG_USER_MYREGISTRATIONALL_TERMS_OF_SERVICE="Согласие с правилами обслуживания" PLG_USER_MYREGISTRATIONALL_AGREE="Я согласен с условиями обслуживания" PLG_USER_MYREGISTRATIONALL_AGE="Мне уже есть 18 лет" PLG_USER_MYREGISTRATIONALL_SHOW_AGE="Подтверждение возраста" PLG_USER_MYREGISTRATIONALL_SHOW_AGE_DESC="Показывать или скрывать чекбокс для подтверждения возраста"

en-Gb.plg_user_myregistrationall.sys.ini

PLG_USER_MYREGISTRATIONALL="User - My Registration - stand-alone" PLG_USER_MYREGISTRATIONALL_XML_DESCRIPTION="Check that the Terms and Age boxes have been checked - stand-alone"

ru-RU.plg_user_myregistrationall.sys.ini

PLG_USER_MYREGISTRATIONALL="Юзер - Моя регистрация - автономка" PLG_USER_MYREGISTRATIONALL_XML_DESCRIPTION="Проверка на согласие с условиями обслуживания и достижения пользователем возраста 18 лет - автономка"