Скабрезный auth registration php
Компонент служит для вывода формы авторизации. Используется обычно в шаблоне дизайна сайта. Компонент является стандартным и входит в дистрибутив модуля. В визуальном редакторе компонент расположен по пути: Служебные > Пользователь .
В визуальном редакторе компонент расположен по пути: Служебные > Пользователь > Форма авторизации .
Если пользователь запросил восстановление пароля, то восстановление происходит по следующему механизму:
- http://site.ru/bitrix/admin/index.php - путь к страницы авторизации или смены пароля;
- change_password=yes - действие смены пароля;
- lang=ru идентификатор языка;
- USER_CHECKWORD=- контрольная строка для смены пароля 32 символа. В строке используются символы. доступные для md5: .
При смене пароля в запросе контрольной строки вводить только контрольную строку, без USER_CHECKWORD= !
- &USER_LOGIN=market - указание для какого пользователя происходит смена пароля.
Примечание . В форме восстановления пароля рекомендуется использовать CAPTCHA - поле Использовать CAPTCHA при восстановлении пароля в настройках Главного модуля.
«Битрикс», 2001-2019, «1С-Битрикс», 2019
Вполне вероятно, что Вы уже слышали про директиву register_globals и знаете, что она делает. Если кто-то этого не знает, то Вы узнаете об этом из данной статьи, однако, главная задача этой статьи доказать, что директиву register_globals лучше всегда держать отключённой в целях безопасности.
Позволяет регистрировать переменные, полученные из GET-запроса . Допустим, был такой запрос: index.php?a=15 . Таким образом, безусловно, создаётся переменная $_GET["a"] и переменная a . Вот создание переменной a и произошло в результате включённой директивы register_globals .
Теперь о том, почему данную директиву надо всегда держать отключённой. Предположим, что Вы делаете авторизацию пользователя, и Вы написали такой код:
Теперь если файл называется, например, auth.php , то, обратившись к нему следующим образом: auth.php?check_user=1 , то получится успешная авторизация, независимо от того, какие логин и пароль были отправлены и были ли отправлены вообще.
Безусловно, данный пример является слегка мистическим, поскольку так никто не пишет (хотя бы из-за отсутствия else $check_user = false; ), однако, данный пример наглядно показывает, к чему может привести включённая директива register_globals .
Теперь о том, как же отключить директиву register_globals . Для этого надо добавить в файл .htaccess всего одну строчку:
Php_value register_globals 0
Есть небольшая вероятность, что если директива была раньше включена, то у Вас может что-нибудь сломаться, поэтому всё внимательно проверьте и устраните все возникшие ошибки, поскольку безопасность того действительно стоит.
В CMS 1C-Bitrix вниманию разработчикам представлено четыре системных компонента для реализации функционалов авторизации, смены пароля и регистрации рядовых пользователей системы (system.auth.*), но отсутствует официальная документация оных. В этой статье вы узнаете ограничения и недостатки использования этих компонентов, почему следует использовать именно их, каким образом лучше их использовать и, возможно, сделаете некоторые выводы о том, почему документации нет.
Принцип работы По умолчанию для авторизации и регистрации используются старые компоненты 1.0, использование которых нежелательно. Исправить это можно, отметив галку «Использовать Компоненты 2.0 для авторизации и регистрации» в настройках главного модуля или однократно выполнив код:COption::SetOptionString("main", "auth_comp2", "Y");
Ознакомившись с описанием порядка выполнения страницы мы видим, что на шаге 1.13 (еще до вывода header.php из шаблона сайта) идет проверка прав доступа уровня 1 и если она не пройдена, то выводится форма авторизации. Разберем это подробнее.
Под вызовом формы регистрации подразумеваются следующие действия:
- порядок выполнения страницы продолжает выполнятся без изменений вплоть до пункта 3 «Тело страницы», включая выполнение header.php,
- вместо «Тела страницы» в зависимости от переданных в $_REQUEST переменных подключается один из системных компонентов system.auth.* (конкретно system.auth.authorize если $_REQUEST пустой), в который передаются особые параметры (об этом ниже),
- порядок выполнения страницы продолжает выполнятся без изменений, включая выполнение footer.php.
Это позволяет реализовать собственный дизайн (шаблон) для компонента system.auth.authorize, органично вписывающийся в шаблон сайта между шапкой и подвалом.
Проверка прав доступа «уровня 1» инициирует вызов формы авторизации в следующих случаях:
- если глобальная константа NEED_AUTH определена и равна true,
- если у пользователя (в том числе незарегистрированного) недостаточно прав для чтения запрошенного им файла.
Права на чтение файлов и разделов для разных групп пользователей формируются при редактировании оных административной панелью в служебных файлах.access.php. Каждый файл описывает уровни доступа к файлам и каталогам, расположенным на одном с ним уровне. Возможно создание файла.access.php для каждого каталога в публичной части сайта, каждый последующий такой файл дополняет правила доступа по цепочке каталогов. Пример такого файла в корне сайта:
Такое распределение прав позволяет буквально «на месте» запрашивать логин и пароль пользователя в случаях когда он переходит без активной авторизации в каталог, функционал которого требует авторизацию. Такое часто случается, если пользователь держит в избранном ссылку не на корень сайта, а на конкретный раздел, с которым больше всего работает. В результате пользователь вводит логин и пароль не уходя с целевой страницы, те отправляются на ее URL, вместо страницы отрабатывает системный компонент обрабатывая полученные данные либо сыпет ошибку либо авторизует и перезагружает страницу. Пользователь доволен, ему не надо совершать лишний клик для перехода в нужный раздел. Программист доволен, ему не нужно думать о редиректах на /auth/ и $backurl.
Использовать же глобальную константу NEED_AUTH рекомендую только в специфических случаях, одним из которых является непосредственно страница авторизации в стандартной поставке демо-сайта по адресу /auth/index.php:
Не редкость, когда боты начинают регистрироваться на сайтах и захламлять списки пользователей своим присутствием. В «1С-Битрикс» можно включить капчу для защиты от спама. Но порой и капча не спасает, да и заставлять пользователей вводить код с капчи, я считаю, не гуманно. Воспользуемся другим трюком.
Этот трюк давно известен: в форму добавляется скрытое или невидимое поле. Если это поле заполнено, значит бот, если нет, значит обычный пользователь.
Разберем на основе регистрацииСкопируем шаблон системного компонента bitrix:system.auth.registration .
В файле template.php этого шаблона добавим новое поле, примерно так:
< tr class = " urdn " > < td > < td >< input type = " text " name = " " maxlength = " 50 " value = " " class = " bx-auth-input " />
В файле стилей шаблона надо прописать правила, чтобы скрыть это поле.
Urdn , .urdn td { display: none ; }
В файл result_modifier.php добавим обработку нашего фейкового поля:
