Но установив защиту, контент редакторы иногда сталкиваются с проблемой размещения некоторых материалов. Проактивная защита запрещает размещать или модифицирует JavaScript или HTML код, который теоретически может быть опасным.
Пару раз я уже сталкивался с тем, что клиенты и партнеры в модуле Проактивной защиты настраивают исключения по путям, в которых защита не работает или вообще отключают модуль. Оба решения очень плохие! Есть штатный способ настроить права для определенной группы пользователей так, чтобы они могли размещать необходимый для работы контент.
Для этого необходимо зайти в Административную панель продукта. Далее...
Настройки-Пользователи-Уровни доступа. Выбрать в фильтре модуль Проактивная защита и добавить новый уровень доступа, давайте его назовем "Право размещать JavaScript".
Следующие два экрана подскажут вам, что нужно указать в новом уровне доступа, чтобы получить необходимый результат:
[spoiler]
На вкладке "Операции, которые содержит данный уровень доступа" укажите разрешение на "Обход проактивного фильтра (security_filter_bypass)"
Половина дела сделана! Теперь вы можете зайти в любую группу пользователей, которым хотите дать право на размещение JavaScript и контролируемый обход Проактивного фильтра и выбрать новую роль в настройках прав доступа группы.
Такой путь мы считаем правильным. Вы сможете работать удобно, и в тоже время не понизите уровень безопасности проекта.
Кстати, мы на всех сотрудников в компании купили Aladdin eToken PASS и авторизация на наших сайтах для сотрудников возможна только с таким вот устройством:
В Журнал вторжений на нашем сайте поступает примерно по 7500 записей за две недели.
Подробнее о Проактивной защите можно почитать или на сайте в разделе .
Эх, не хочется вас расстраивать.
Вот вам примерный сценарий. Машина сотрудника заражена вирусом и попадает в ботсеть, с его машины крадут все пароли на доступ к сайту и с нее же с IP сотрудника входят на сайт...
Кстати, известны примеры, не выдумка.
При наличии одноразового пароля сценарий усложняется необычайно!
Поскольку такая опция применяется для контент-менеджеров, то имхо не следует их путать абсолютно ненужной им вещью - вкладкой с настройками модуля, пусть даже и с правами RO
Кстати, мы на всех сотрудников в компании купили Aladdin eToken PASS и авторизация на наших сайтах для сотрудников возможна только с таким вот устройством:
То же сейчас на одном проекте рулю через .htaccess. Локальных пользователей пускаю через авторизацию битрикс, а остальным (из вне) приходится еще и логин с паролем дополнительно вводить.
Сообственно вопрос, а можно ли сделать что бы локально (по айпишнику) пользователь логинился без проблем, но если из вне он логинится (после ввода логина и пароля апача) при авторизации битрикс еще и OTP подключался... Есть у меня одна группа которую надо так защитить ...
Т.е. из внутренней локалки он должен логинится очень просто, даже без ввода пароля (там наворочено и так все железками), а вот из вне что бы пароль + OTP работало.
Т.е. из внутренней локалки он должен логинится очень просто, даже без ввода пароля (там наворочено и так все железками), а вот из вне что бы пароль + OTP работало.
Мы уже думали с Юрой об этом. Так как подключение на КП OTP привело к неудобствам.
Видимо найдем решение и параметры для настройки.