Возникла ситуация, в которой необходимо добавить в один конкретный комментарий картинку со своим встроенным стилем (<img style="перечень стилей" src="адрес картинки">). Если мы добавляем картинку без стилей, то задача решается без проблем. Если же стили содержатся, то система фильтрует такую картинку, выводя сообщение:
Внимание! Возможна XSS-атака!
Вот скриншот:
Есть ли прием, позволяющий все же добавить стиль к картинке?
Еще хотелось бы применить скрипт после какого то конкретного комментария, т.е. после текста комментария шла конструкция:
<script type="text/javascript">Тут Сам скрипт</script>
Но система фильтрует это, что мешает реализации некоторых вещей.
Заранее спасибо!
9 3667
Еще записи по теме
- Почему в результате любых изменений через админку исчезает шапка сайта?
- Как вывести последние записи блога на произвольной странице?
- Возможно ли в статьях использовать IFRAME?
- Плагин галереи с пакетной обработкой картинок
- Почему не выводятся RSS в категориях?
- Работает ли MaxSite CMS на PHP 5.6.xx и выше?
- Где искать стили шапки шаблона d3?
Катя, фильтрация на xss-атаку сделана не просто так и ваша задача в общем случае ставит под угрозу безопасность сайта. Поэтому готовых решений особо никто не публиковал. Но думаю, что попробовать помочь вашей проблеме вполне можно. Вот мои соображения.
Если вы проанализируете функцию mso_get_new_comment (в файле \application\maxsite\common\comments.php), то увидите обращение к хуку mso_get_new_comment_args, из названия которого можно догадаться, что он предназначен для переопределения параметров обработки нового комментария.
Получается, что нам нужно переопределить значения некоторых ключей массива в переменной $args, который будет передан обработчику хука. В частности, вас должны интересовать $args['tags'], $args['xss_clean_die'] и $args['xss_clean'].
Если задать указанные значения то всем комментаторам станет доступна возможность XSS атаки. Это нехорошо и чревато. Поэтому желательно в обработчике хука ограничить переопределение ключей только для залогиненных пользователей, а то и вообще только для главного админа (т.е. для юзера с определённым id).
Общую логику я описал. Код можно разместить в ушку (тип PHP) и заставить вызываться ушку по упомянутому хуку (с помощью плагина ushki_to_hook).
Готового кода сейчас пока нет, так что предлагаю попробовать реализовать его самостоятельно и поделиться с нами результатом
Спасибо, Илья!
Как думаете, верна ли логика: делаем такой плагин (отключение защиты для пользователя с определенным ID). Далее, когда нам нужно использовать в каком-то комментарии расширенный функционал, то мы включаем этот плагин, указываем ID пользователя, который его оставил, получаем неограниченные возможности для редактирования комментария. После того, как получим желаемый результат, удаляем этого пользователя из списка плагина (или просто выключаем плагин). Получается, что в будущем данный пользователь самостоятельно уже не сможет обойти защиту (да и вообще никто не сможет). Вроде неплохо.
Дело в том, что если мы дадим админу возможность комментировать без проверки на атаку, он ведь все равно не сможет редактировать чужие комментарии с отключенной защитой? Так как комментарий не от его имени. Логика такая?
Катя, если админов несколько и админ, которому разрешается вставлять в комментарий подозрительный код, не является супер-админом, то возможно ваша логика и верна для случая постинга комментария через сайт. Но при беглом осмотре кода панели редактирования комментариев я не увидел проверки на авторство комментария. Да и хука типа mso_get_new_comment_args - не видно. Поэтому с администрированием комментариев ситуация немного сложнее и требует отдельных исследований.
Вы могли бы описать суть проблемы, которую пытаетесь решить? А то непонятно зачем все эти сложности - вдруг найдётся более изящное решение?
Суть проблемы: допустим, некий посетитель (пусть будет анонимом) оставил очень полезный комментарий. Хотелось бы иметь возможность (админу) полноценно его отредактировать. Это конечно не каждодневная ситуация... Но, столкнувшись с ней (ситуацией), не смогла придумать как обойти защиту.
Все бьюсь над этой задачей =)
Если мы редактируем функцию mso_get_new_comment, убираем фильтр XSS-атак, то система пропускает такой комментарий и он записывается в базу данных. Однако, когда он выводится на страницах сайта, то из БД он считывается функцией mso_get_comments и все равно срабатывает фильтр от XSS (хотя в БД комментарий записан в нужном виде). Как сделать, чтобы, например, комментарий с определенным ID система не фильровала?
Подозреваю, что в системе нет таких возможностей - Максим не склонен добавлять в систему функционал "про запас". Поэтому видится возможным только один вариант - реализация кастомных функций сохранения и получения комментария со всей необходимой вам логикой работы.
Илья, скажите, пожалуйста, какой именно код в mso_get_comments урезает/фильтрует? Можно ли сделать проверку: если комментарий с таки-то ID, то данный код не выполняем? Может там хук какой есть, чтобы саму функцию не править?
Спасибо!
Катя, в коде функции mso_get_comments вижу хук comments_content_custom, в который передаётся содержимое комментария. Вполне возможно, что будет достаточно создать свой обработчик (задав ему нужный приоритет чтобы обрабатывался первым).
Если обработчика хука нет, то содержимое камента передаётся функции mso_comments_autotag.
Спасибо, Илья! Самостоятельно не получается такое сделать