Если на форуме создать тему и в теле темы разместить пост со знаками слеш в обратную сторону\
То обрезается пост после создания темы и эти слешы конечно удаляются.
Баг на форуме. 1.10.6
ЕСТЬ РЕШЕНИЕ
ЗАКРЫТО
#2
11 июля 2015 в 02:42
Коллеги, проверьте у себя этот баг.
#3
11 июля 2015 в 10:45
Проверил. Пост не обрезается. Но сами слеши пропадает. Если где то поставил два слеша остается один. В другой раз от семи осталось 3.Коллеги, проверьте у себя этот баг.
Сегодня в 07:18
В текущих реалиях эту особенность не победить. Можете в файле /core/classes/db.class.phpТо обрезается пост после создания темы и эти слешы конечно удаляются.
строку
Геннадий Иванович, вы наверное невнимательно прочитали мой ответ или до конца не понимаете сути и исторического нахождения в указанной строке функции stripcslashes, которая УБИРАЕТ экранирование из строки, а ПОТОМ эта же строка еще раз экранируется посредством mysqli_real_escape_string для безопасности sql запроса.
Удаление функции stripcslashes (именно stripcslashes а не stripslashes) не приведет к фатальным результатам по безопасности.
И я прекрасно понимаю, что на этапе получения данных из $_REQUEST не нужно экранировать данные посредством mysqli_real_escape_string, но у нас они именно там экранируются исторически и чтобы изменить это поведение нужно переписывать почти весь движок, чтобы вынести логику экранирования данных непосредственно перед выполнением запроса в базу (например как это сделано в двойке).
Поэтому сейчас есть так, как есть, но с одним нюансом, что обратные слеши вырезаются (stripcslashes это делает). Кроме этого, stripcslashes возвращает обратно спецсимволы перевода строки из буквального представления \n в их символьное представление дабы потом в текстах не было букв \n.
Удаление функции stripcslashes (именно stripcslashes а не stripslashes) не приведет к фатальным результатам по безопасности.
И я прекрасно понимаю, что на этапе получения данных из $_REQUEST не нужно экранировать данные посредством mysqli_real_escape_string, но у нас они именно там экранируются исторически и чтобы изменить это поведение нужно переписывать почти весь движок, чтобы вынести логику экранирования данных непосредственно перед выполнением запроса в базу (например как это сделано в двойке).
Поэтому сейчас есть так, как есть, но с одним нюансом, что обратные слеши вырезаются (stripcslashes это делает). Кроме этого, stripcslashes возвращает обратно спецсимволы перевода строки из буквального представления \n в их символьное представление дабы потом в текстах не было букв \n.
#6
11 июля 2015 в 17:05
А где вы увидели что написал об отказе от mysqli_real_escape_string? Видимо все же невнимательно прочитали. Еще раз, то, что я ответил в рамках вопроса данной темы никак не отразится на безопасности. Где вы увидели отговорку и простые фразы, я не знаю.Обоснуйте отказ от mysqli_real_escape_string
действительно, без комментариев, я вам про ерёму, вы мне про фому.{,tp rjvtymfhbtd}
#7
11 июля 2015 в 17:37
сделаю вид, что не замечаю вашего хамстваибо он выглядит нелепо
я ничего не удалял. вы упорно не понимаете того, что я написал.методом удаления правил самой самой безопастности
#8
11 июля 2015 в 20:51
Ответ в #4