Sander1
-
Публикации
119 -
Зарегистрирован
-
Посещение
-
Дней в лидерах
20
Сообщения, опубликованные пользователем Sander1
-
-
Ладно, я понял, что в этом вопросе у нас в корне разный подход к обработке пользовательских данных...
Я придерживаюсь общепринятой практики, что данные необходимо хранить в чистом виде не изменяя их и не уничтожая.
Если я написал заголовок Пример <script>alert('test')</script> & \" © – то именно в таком виде он должен сохранится в БД без преобразований и замен. И именно это должен видеть пользователь на странице сайта.Задача программиста обеспечить лишь безопасность:
1. Сохранение этих данных в БД
2. Отображение данных на сайте (админка, пользователю, метатеги, rss и т.д.)В первом случае для этого достаточно $db->safesql(), хотя лучше бы ->prepare, но и так сойдёт. Никаких дополнительных addslashes и htmlspecialchars не нужно.
Во втором – использовать htmlspecialchars() с соответствующими флагами, как раз чтобы браузер воспринимал этот заголовок как обычный текст, а не как код или html сущности.-
1
-
-
22.10.2024 в 16:42, celsoft сказал:
Заголовок должен быть написан текстом и нормальными символами, а не HTML кодом.
С этим я согласен. И вот именно в это суть данной темы. Парсер DLE распознает в тексте заголовка html сущности и заменяет их на соответствующие символы:
" → " & → & и т.д.Т.е. если я написал заголовок:
Пример & / & / <b> / " / ' / ©
То в таком и именно в таком виде заголовок должен хранится в БД. В DLE же он меняется и сохраняется у же порезанным и преобразованным
В БД: Пример & / & / / \" / \' / © Что видит пользователь на странице: Пример & / & / / " / ' / © На сайте в исходном коде: <title>Пример & / & / / " / ' / ©</title>
При выводе на сайте, хоть в теле страницы хоть в метатегах достаточно один раз использовать htmlspecialchars($title, ENT_QUOTES | ENT_HTML5, 'utf-8');
Без последующих костылей вида str_replace('&amp;', '&', $title);При нормальном использовании исходный заголовок в исходном коде страницы должен выглядеть так:
<title>Пример &amp; / & / <b> / &quot; / &#039; / &copy;</title> <meta property="og:title" content="Пример &amp; / & / <b> / &quot; / &#039; / &copy;"> <h1>Пример &amp; / & / <b> / &quot; / &#039; / &copy;</h1>
И пользователь на странице будет видеть заголовок именно так как задумано и написано в поле заголовка.
К вопросу о безопасности. Я помню этот баг, когда в метатеге заголовка писали тег {content} и движок распознавал его как тег, а не как текст, что действительно ломало верстку. Для этого сейчас вы дополнительно добавили строку:
$text = str_replace(array("{", "}", "[", "]"), array("{", "}", "[", "]"), $text);
Но вот проблем с обратным слешем я не вижу вообще никаких. Суть-то в чем. Этот слеш можно написать и сохранить, но его приходится вручную экранировать, чтобы его не вырезал stripslashes, который вообще хз зачем там нужен.
16 часов назад, celsoft сказал:Вы не привели.
Вы задали вопрос – зачем писать html сущности в заголовке. Я просто в гугле нашел первую страницу где в заголовке написано текстом &
Я не смотрел и не приводил тот сайт как образец правильности заполнения метатегов. Но согласен, что &amp;amp; – это очевидно баг, они взяли экранированный заголовок и повторно экранировали его в описании.16 часов назад, celsoft сказал:Для чего такую конвертацию проводить?
Вот именно этим вопросом я задаюсь глядя на код в DLE.
1. При сохранении $parse->process заменяет & на & и сохраняет в таком виде в БД.
2. При формировании метатегов в $meta->title($metatags['title']); выполняется вызов метода Helper::escape в котором сначала выполняется замена сущностей на символы html_entity_decode и затем опять экранирование в htmlspecialchars.Я понимаю зачем и почему так сделано, но это всё лишь следствие неправильного хранения данных.
Причем в оригинальном методе класса этого двойного преобразования нет, там только один htmlspecialchars. -
9 часов назад, celsoft сказал:
Я посмотрю, потому что если честно я на память не помню уже, очень старая функция DLE, и в ней очень давно не было никаких изменений. Но сразу задам вопрос. По вашему ссылки и содержание метатега это одно и тоже? В данной теме автора беспокоят ссылки в HTML документе и для ссылок действительно крайне важно писать & вместо &. А какой тайный смысл писать это в описании? Для чего в описании писать & вместо &? Какой то потребности в этом нет. Поэтому не совсем понятно в чем именно заключается проблема.
Суть не в том что там обсуждается. Вы задали вопрос – зачем нужна возможность отображения & в заголовке, я привел пример страницы где как раз в заголовке используется & как текст, а не как html сущность.
Правильно ли заменять HTML сущности на соответствующий символ внутри текста – это отдельная тема и тут нет однозначно правильного мнения.
К примеру на этом форуме если я пишу < в тексте, то он и выведет < и не заменит на <Повторю основную суть. В DLE невозможно создать, к примеру, такой заголовок:
Почему в адресе необходимо использовать & вместо & -
2. Откройте страницу по ссылке. Скопируйте тот заголовок и вставьте его в DLE.
Вот в этом проблема, что НЕВОЗМОЖНО получить на выходе такой же заголовок как там. Будет так:Why should I use & instead of &?Вместо правильного:
Why should I use & instead of &?Да даже на этом движке форума, я уверен, если в заголовке прописать & то на странице он так же и будет показан, а не заменён на &.
-
1. В обычный заголовок пишу `Пример \ слеша`, в теле страницы вижу заголовок:
<title>Пример \ слеша</title>
Если же в метатег заголовка прописать `Пример \ слеша`, то в теле страницы будет:
<title>Пример слеша</title>
Получается в одном случае это опасно, в другом – нет?
2. Зачем... Например чтобы можно было сделать такой заголовок:
https://stackoverflow.com/questions/35367945/why-should-i-use-amp-instead-of -
1. В метатеге заголовка невозможно использовать обратный слеш: \
Его получится использовать, если экранировать его вручную прописав \\\\, но после повторного сохранения слеш всё равно пропадёт.
Т.е. stripslashes есть, а addslashes нету.2. Невозможно нормально использовать HTML сущности в основном и мета заголовке.
К примеру мне нужно, чтобы был именно такой заголовок в таком же виде:Пример "замены" © на ©После сохранения новости в БД записывается "исправленный" заголовок (причём ещё зачем-то дополнительно экранируется двойная кавычка):
Пример \"замены\" © на ©Возможно так действительно правильнее/удобнее. Для таких редких случаев можно вручную экранировать символ & → &
Но проблема в том, что после повторного сохранения – опять получим "исправленный" заголовок.
Пишу заголовок:Пример &quot;замены" &copy; на ©В БД он записывается в таком же виде (разве что кавычка лишний раз экранируется слешем).
На сайте в заголовке и на странице он отображается корректно именно так как задумано (чтобы писало " и © текстом)Открываю редактирование и вижу уже "исправленный" заголовок:
Пример "замены" © на ©Ну и после сохранения, соответственно, полностью теряется исходный заголовок.
-
Кеш создаётся относительно значения SQL запроса в переменной $this->query
if ( $allow_cache ) $rows = dle_cache ( "comm_".$allow_cache, $this->query );В show.full.php этот запрос формируется со значением
$where_approve = " AND " . PREFIX . "_comments.approve=1";В engine/ajax/comments.php добавлены одинарные кавычки
$where_approve = " AND " . PREFIX . "_comments.approve='1'"; -
Я-то думаю, чего это все модули посыпались и стали требовать обязательной передачи пустого параметра ShowLoading('')
if (typeof positiony == 'undefined') { var positiony = 'center'; } if (typeof message == 'undefined') { var positiony = ''; }
Два раза positiony вместо message
-
1
-
-
Пример:
{custom idexclude="{news-id}" category="1,2,3" limit="10" order="reads"}Если открыть не существующую (удалённую) новость, то тег {news-id} не будет обрабатываться из-за проверки defined('NEWS_ID') :
if( defined( 'NEWS_ID' ) AND !$this->is_custom) $content = str_ireplace( "{news-id}", NEWS_ID, $content );
В результате в шаблоне будет обработан custom на основании строки:
{custom idexclude="{news-id}А оставшаяся часть строки:
" category="1,2,3" limit="10" order="reads"}будет отображаться как текст.
-
1
-
-
5 часов назад, celsoft сказал:
Какое есть. Нам нужно было зарезервировать какой то символ. Было принято решение что именно этот.
Я понимаю причину такого решения. Полагаю в текущей реализации работы с доп.полями это действительно единственный наименее болезненный выход.
Основная суть посыла в том, что необходимо как-то уведомлять пользователя о запрете использовать запятые, а так же "новое не должно ломать старое".3 часа назад, aleksandrhristich сказал:Второй пункт не логичный какой-то
Да это просто выдуманный нежизнеспособный пример. Речь не бизнес-логике воображаемого приложения, а о неочевидном для пользователей изменении поведения поля при наличии запятой в списках.
39 минут назад, Gameer сказал:Эм, а можно строку и брать разделитель на разбивку тот который указан в доп поле и сделать для данного типа списка его обязательным.
Будут проблемы при смене символа. Если сейчас `,`, а потом в шаблоне надо будет `/`, то придётся выполнять перестроение всех полей с заменой `,` → `/`. А это как-то не логично и накладно. И опять же, будут проблемы если в значении поля уже используется символ `/`, то получим ту же проблему что и в топике.
Как вариант возможно можно было бы рассмотреть вариант с хранением данных в json формате. Ранее, когда JSON не работал с кириллицей, вариант с кастомным форматом `поле|значение||поле2|значение2` был вполне приемлем. Но сейчас, как мне кажется, использование json будет наиболее приемлемым.
Это решит многие проблемы и позволит более гибко хранить данные с различными дополнительными параметрами, как у загружаемых изображений к примеру.
Так же позволит использовать цельные значения доп.полей без необходимости костылить/заменять запятые, например подборки `Про мафию, банды и мошенников`.Я уж молчу о файле xfields.txt Он уже давно просится перейти на json формат. Строка вида `||text||1|0|0|0|||0|0||||||||||||||` вызывает лишь отчаяние при попытке понять какие там параметры в ней прописаны.
-
Нууу, очень спорное решение в данном случае.
Вообще нигде не указано, что теперь нельзя использовать запятую в списках.
Человек просто заметил, что поле не сохранилось. Нет никаких ошибок или сообщений при использовании запятой в поле.Основная суть проблемы в том, что:
1. Поменялась логика поведения прежнего функционала даже при выключенной опции мультивыбора.
2. Нигде не написано, что теперь нельзя использовать запятую в значении поля списка. Оно просто молча перестало работать как было раньше.Почему я считаю это критической ошибкой.
Допустим это интернет магазин, в поле "Наличие" прописаны значения:Есть, в достаточном количестве Есть, под заказ Нет, ожидается поставка Нет, снято с производстваПри редактировании будет всегда автоматически выбираться первое значение. И если админ не сразу заметит (а он не сразу заметит), то большое количество данных будет утеряно. И придётся немного помучаться, чтобы восстановить данные из бекапа. И будет хорошо, если всё ограничится лишь восстановлением данных...
-
1
-
-
Проблема связана с добавлением функционала Разрешить выбор нескольких значений
Значение в списке имеет вид:Да, можноВ /engine/inc/xfields.php теперь все значения списка по умолчанию обрабатываются словно включен мультивыбор и разбиваются по запятой:
$fieldvalue = explode(',', $fieldvalue); → line: 1178
Т.е. в БД строка имеет вид:
field|Да, можно||other|valueгде `Да, можно` – это одно цельное значение. А скрипт обрабатывает его словно это перечень значений.
В результате чего при каждом редактировании новости слетает выбранное прежде значение.
В коде идёт сравнение строки `Да, можно` из списка и массива [`Да`, ` можно`]. Что и приводит к некорректному результату.in_array($value1[0], $fieldvalue)
-
Если при редактировании/создании RSS информера оставить поле выбора категории пустым, то будет Fatal Error. PHP 8 для функции count() теперь выбрасывает ошибку если ей передан не поддерживаемый тип, в данном случае NULL.
engine/inc/rssinformer.php
if( !count( $category ) ) { -
Не-а. Не указано.
ЦитатаМаксимально допустимый вес изображений, загружаемых для публикаций
Введите максимальный объём загружаемого изображения (в килобайтах)Да и в целом неплохо бы добавить "защиту от дурака".
К тому же проблема только в файле categories.php. Во всех других файлах этой проблемы нет.
-
Fatal error: Uncaught TypeError: Unsupported operand types: string * int in /engine/inc/categories.php:127
$max_file_size = (int)($config['max_up_size'] * 1024);
Нужно так:
$max_file_size = (int)$config['max_up_size'] * 1024;
В конфиге:
'max_up_size' => '', -
Комментарий удаляется из БД прямым запросом игнорируя параметр древовидных комментариев.
Получается что если у комментария были ответы, то из поста пропадает вся ветка, хотя комментарии-ответы по факту существуют.
-
35 минут назад, celsoft сказал:
DLE делает все правильно
Комментарий отправляется на модерцию. Счётчик новости не меняется. Зачем в таком случае чистить кеш?
engine/modules/addcomments.php
Перед строкой:clear_cache( array( 'news_', 'comm_'.$post_id, $cprefix, 'stats' ) );Достаточно добавить код:
if ($where_approve)И обратите внимание на п.2. При подтверждении комментария через AJAX обработчик не очищается кеш комментариев новости.
PS. И ещё, чтобы отдельную тему не создавать. Пользователь с именем `noname` проклят невозможностью выставлять оценки в рейтинге.
Все гости записываются в таблицу `dle_logs` и `dle_comment_rating_log` под именем `noname`.
Может будет правильнее для гостей записывать NULL или хотя бы пустую строку в качестве имени? -
Проблемы с очисткой кеша.
1. При добавлении коммента, который уходит на модерацию – всё равно чистится кеш. Самое плохое что чистится кеш всего контента – `news_`
2. При ajax подтверждении комментария – излишне чистится почти весь кеш всего сайта, кроме того который реально необходимо чистить – `'comm_' . $post_id`
-
В админке в расширенном поиске новостей добавить возможность поиска по исключению.
К примеру – найти все новости где доп.поле НЕ содержат строку poster|Какой-нибудь селектор со списком выбора, к примеру:
Содержит Не содержит Строго равно Начинается на Начинается НЕ на Заканчивается на Заканчивается НЕ на-
1
-
1
-
-
Не охота создавать отдельный топик, файл engine/ajax/adminfunctions.php – небольшая опечатка:
index.php??subaction
PS. К слову в этом файле для метода commentspublic тоже можно добавить проверку существования коммента на всякий случай.
-
При массовом подтверждении комментариев если случайно обновить страницу и подтвердить повторную отправку формы, то в новостях будет повторно увеличен счётчик comm_num+1
Не выполняется проверка на существование комментария и находится ли он на модерации. -
Парочка предложений по утилите управления плагинами.
1. Есть параметр `Обязательное наличие плагина`. Но он поддерживает только один плагин. А иногда когда делаешь комплексную систему – идёт связка из нескольких отдельных модулей. Идеальным вариантом было бы использование чего-то подобного конфигурационному файлу composer-а, например что-то примитивное типа:
{ "name": "Sandev\CurrentModName", "require": { "php": "^7.1 || 8.1", "dle": ">=14.2 && <16.0", "Sandev\RequiredModule": "*", "Sandev\AnotherRequiredModule": "*", } }
А если сюда ещё добавить и autoload-psr4, то будет вообще сказка.
2. На странице списка плагинов сделать поиск на JS, чтобы был без перезагрузки страницы.
А если развить тему из п.1, то было бы очень удобна организация быстрого поиска по vendor-у. Выводить список авторов на подобии облака тегов.3. На страницу плагина добавить все элементы управления плагином, а не только "Сохранить". Это прям вот вообще необходимо.
4. В списке плагинов добавить обычную ссылку на страницу редактирования плагина, чтобы можно было открыть редактирование плагина в новом окне.
Комментарий по п.3 и п.4: Заходишь на незнакомый сайт, нужно выполнить оптимизацию. А там 50+ плагинов и часть из них имеют имена `rate fav img`, `JS скрипты`, `Новое` и т.п. Приходится открывать плагин, смотреть что там, потом возвращаться назад, вновь искать этот плагин в огромном списке чтобы выполнить любое действие над ним кроме сохранения. Это жутко неудобно.
И незначительный багрепорт. Если первый в списке плагин переместить вниз, то у него не будет верхней кромки из-за наличия класса `no-border-top`. Странно зачем вообще так сделано если можно просто стилями всё оформить:
.table tbody tr + tr td {border-top: 1px solid:#ccc}
-
На почту отправляется одноразовая ссылка для восстановления пароля, при переходе по которой удаляется запись из БД и повторно воспользоваться ею нет возможности.
Некоторые почтовые сервисы самостоятельно выполняют переход по ссылке (для проверки на вирусы или ещё с какой-то своей целью), в результате чего пользователь имеет не рабочую ссылку восстановления.PS. Простое решение, добавляется проверка IP адреса, чтобы страница сброса пароля работала только если её открыл тот же IP адрес с которого выполнялся запрос на восстановление.
https://github.com/San-Dev/dle-plugins/blob/master/lostpassword-by-ip.xml-
3
-
-
18 часов назад, celsoft сказал:
При использовании где? DLE нигде вообще не использует DIRECTORY_SEPARATOR поэтому почему он вдруг его должен как то заменять?
Да, в движке сейчас нигде не используется. Но ведь система создана для плагинов, вот про них и речь.
Взять тот же /engine/classes/composer/vendor/composer/ClassLoader.php в нём эта константа используется.Можно сказать, это даже скорее не баг, а небольшое пожелание для будущих версий.
PS. Проблема возникла в самописном автозагрузчике классов.
Последние комментарии
в Прием багов
Опубликовано: · Изменено пользователем Sander1
Есть похожий баг (хотя может так и задумано).
Если снять публикацию с модерации, то комментарии от этой публикации и ссылки на неё всё равно будут отображаться в customcomments.
UPD: Увидел ответ в соседней теме, вопрос снимаю.