Что делать с данными, приходящими от пользователя?

[_RVK_]

kruglov
Нет. Это тот случай, когда у тебя вся свобода действий.
1. Ты загружаешь его фото, если задача позволяет грузит любые фото.
2. Ты преобразешь его фото для показа на своем сайте, при этом оставляешь ссылку на оригинал.
3. Ты говоришь что его фото слишком большое, пож. уменьшите размер.
4. Ты молча, корячишь фото пользовтеля, который потом покрывает тебя матом и бежит с твоего сайта.

Пример http://photofile.ru где твоя фото сохраняется в первоначальном размере, и ты всегда можешь её как просмотреть так и скачать.

 

[Royal Flash]

Каким образом лучше хранить текстовые данные с разметкой в CMS?
На первый взгляд, можно сохранять их as is, со всем HTML, Java и т.д., так допуск к записи тех-же новостей, статьей и др. имеет администратор, с полными правами доступа, чем возможностей больше - тем лучше. Вариант с ограничением прав доступа я здесь не рассматриваю, так как в этом случае уже необходимо применять фильтрацию входящих данных на наличие запрещенных последовательностей.

Проблемма появляется, когда выполняется полнотекстовый поиск ( FULLTEXT ), по этим материалам.
Введя "table", или любую другую буквенную управляющую последовательность (невидимая пользователю: HTML теги, CSS и т.д.) получаем много неккоректных результатов поиска, так как слово table содержится в базе, следовательно будет найдено, вот только "<table width=100 ...." пользователь, естественно не увидит.
Разделять многомегабайтовую базу статей на чистый текст (для поиска) и текст с форматированием (для вывода), как советовали в этом топике не выход - дисковое пространство сервера, всеже, нужно использовать оптимально.

 

[Kirs]

Royal Flash выше уже предлагалось для этих целей использовать отдельную запись в базе, где будет храниться уже оптимизированный для поиска текст.

Место сейчас дешевое, так что это нормально.

 

[Royal Flash]

Kirs
Это смотря сколько тебе этого места нужно. Если речь идет о паре-десятке мегабайт - применить данный вариант возможно, хотя выглядит он уж очень не красиво. В моем случае, это база с приростом по 20-40 метров в месяц, что через года два раздует только 1 базу до 1 Gb. Зачем мне еще вторая, занимающая почти столько-же? Нерационально, товарищ Kirs...

-~{}~ 17.12.05 04:58:

Возможно всеже есть вариант, как не индексировать теги и т.д. в FULLTEXT`e?

 

[Kirs]

Royal Flash - IMHO если делать криво (т.е. хранить в базе отформатированный текст) - можешь шифровать тэги (так, чтоб не попадались при поиске) - при выводе - расшифровывать (это если не хочеш тратить больше дискового пространства и не загружать сервер хитрыми запросами).


По теме:

Считаю, хранить в базе (в не заданных определенным форматом полях) надо как есть, а выводить как нужно, т.е. в HTML, в XHTML, в виде только текста, в виде Word/Exel документа, PDF... для любого вида вывода можно написать свою библиотеку, которая будет форматировать исходный текст в необходимый формат - вырезать, экранировать, обрабатывать и т.п. а не гадать над входящими в нее из базы данными - что есть &lt; - полноценное начало тэга (просто обработанное на входе в базу) или просто обычный набор символов. Если все же нужна разметка текста - BB коды, которые также будут представлены на выходе в необходимом на данный момент формате. Так в базе всегда будет универсальное (а не отформатированное понятным только текущему програмисту образом) представление данных.

Да и согласен с тем, что нужно заставлять пользователя корректировать данные (если они заданы определенным форматом), а не оставлять эту роль программе. Если человек ввел в цифровое поле вместе с цифрами - букву, почему нужно считать, что "откорректировав" (т.е. удалив недопустимый символ) мы получим корректное число? Я считаю, что корректное число/строку (пусть даже и левое) мы получим только после того, как его корретно (в нужном формате) введет пользователь.

 

[Royal Flash]

KirsТо что ты предлагаеш - это ОЧЕНЬ криво: шифровать все возможные HTML теги, Java-scripts, CSS и т.д. - весьма и весьма трудоемкий процесс, который, требует постоянных обновлений.

 

[Kirs]

Royal Flash - почему? При вводе в базу, один раз, корячишь необходимым образом все что между "< и >", между "<script> и </script>" "<style> и </style>" (хотя непонятно что у тебя в базе делает JS и CSS), а при выводе расшифровываеш. Процессорные затраты минимальны, дисковое пространство не страдает... все в идеологии "хранить в базе отформатированные данные", т.е. хранение данных заточнео непосредственно для поиска по базе.

 

[Royal Flash]

Kirs
В базе:
<table bgcolor="#FFFFFF" width="100%" cellpadding="0" cellspacing="0" border="0">
Ты предлагаеш "корячить" слова: bgcolor, FFFFFF, width, cellpadding, cellspacing, border?? Если этого не сделать, они будут найдены, хотя такого быть не должно.

Если не прочитал внимательно, то что я написал, или не знаеш как работает FULLTEXT - просьба не флудить в данном топе. BB коды нужны чобы не пропустить ненужные, опасные последовательности, но полностью не подходят для решения проблем с поиском.

Возможно заменить все что между "< и >", между "<script> и </script>" "<style> и </style>" на уникальные ссылки, например:
<table bgcolor="#FFFFFF" width="100%" cellpadding="0" cellspacing="0" border="0"> на S#100234, в другой таблице хранить расшифровку. Только это очень тормазнутый вариант по скорости его обработки перед выводом пользователю: тегов на странице, и соответственно операций по кодированию и раскодированию будет немеряно.

 

[sage]

Так... вернулись в самое начало топика.... )
Kirs

хотя непонятно что у тебя в базе делает JS и CSS

А почему бы и нет?

При вводе в базу, один раз, корячишь необходимым образом... а при выводе расшифровываеш

Вот про это и разговор. Стоит ли игра свеч? Зачем по сто раз делать одно и тоже: кодировать, декодировать, потом снова кодировать и т.д, если можно сохранить as is, а уже при выводе парсить. Не знаю, лично мне, это ближе и тут я полностью согласен с _RVK_, SiMM и master_x (по-моему, никого не забыл )

 

[Kirs]

Royal Flash ё-маё... ну чего тут непонятного. Я же говорю в контексте данной темы. Тут предлагают сохранять вместо (человеческое) ">" - (HTML безопасное) "&gt;". Ты, если хочешь идти по данному пути, можешь сделать то-же самое, вместо (HTML формат) "<table>" сохраняй (формат "пропустить при поиске") "&xxxGt5Frfd;", вместо "<script>...</script>" сохраняй "&xxxjHjIkkh7H6hklhjKkyu8HghH;" и т.п. в соответствии со своим алгоритмом шифрования, т.е. то что человек искать не будет, или программа не выдасте это ему. Это как вариант кривого исполнения твоих требований.

sage Я, в общем, тоже полность придерживаюсь этих взглядов, начсет as is (через мой пост выше).

 

[sage]

Kirs

Это как вариант кривого исполнения твоих требований

Это не его требований, это вариант исполнения твоих КРИВЫХ идей ) Мне кажется, что вопрос исчерпан. Началось повторное переписывание того, о чём говорилось в начале топика. Подытожив всё вышесказанное, _RVK_ дал исчерпывающий ответ, который всем советую распечатать (уже сделал ) или запомнить, как кто хочет... )

 

[Kirs]

Автор оригинала: sage
Это не его требований, это вариант исполнения твоих КРИВЫХ идей )

Человек столкнулся с такой проблемой. Что sage посоветует данному человеку в концепции "исчерпывающего ответа _RVK_" (кроме увеличения финансового вливания в хостинг, чего как видно не входит в планы решения данной проблемы).

 

[svetasmirnova]

Человек столкнулся с такой проблемой. Что sage посоветует данному человеку в концепции "исчерпывающего ответа _RVK_" (кроме увеличения финансового вливания в хостинг, чего как видно не входит в планы решения данной проблемы).

О! Кстати, я посоветую Полнотекстовый поиск настраивать.

 

[_RVK_]

Господа, замечания по поводу дискового простраства еще более глупы нежели по поводу процессорного времени. Всегда затраты на оплату работы проограмистов выше цены нового, не то что винта, СЕРВЕРА! Но, дело не в винтах. И даже не в проблемме поиска. Я уже советовал смотреть рядом. Наберите запрос "table" в гугле. Если вы не в силах реализовать такое, введите себе отдельное поле, но помните, что это тот же поисковый индес, только через Ж.

PS. Странным образом переплитатся различные проблеммы веб-программироания в одной теме. Но думаю для сопутствующих проблемм этот топик не подходит. Поиск - абсолютно другая тема, которая решается в обоих случаях. Вопрос в том, КАК она решается.... но это совсем другая тема....

-~{}~ 17.12.05 20:40:

Кстати, эта тема создавалась не для профи, а для новичков. И меня радует, что новички выбирают правильную позицию. "Стариков" переучивать нет смысла. Просто это уже из области психологии. Опять же совершено другая тема.

 

[Royal Flash]

svetasmirnova
Если бы еще был совет где об этом почитать - был бы благодарен.


_RVK_
Была такая замечатеьная реклама: "Зачем платить больше"? Зачем переплачивать за дисковое пространство, если, как мне кажется, этого можно избежать не прибигая к большим затратам человечесского времени? Вот только как этого избежать я и пытаюсь выяснить. Да и поиск, имеет прямое отношение к наполнению, хранящемуся в базе, в своей теме я это четко обрисовал.
Создавая базу данных наполнения, нужно заранее предусматривать все возможные варианты использования этой бызы, включая и поиск по ней, а не переделывать потом огромную работу, что повлечет за собой "оплату работы проограмистов". Данные приходящие от пользователя зачастую могут быть и объектом поиска.

 

[svetasmirnova]

Royal Flash
Какую базу используете? Для MySQL это глава 6.8.2. официального мануала: "Тонкая настройка полнотекстового поиска в MySQL"
Наводка что смотреть:

Список стоп-слов может быть загружен с файла, указанного в переменной ft_stopword_file. See Раздел 4.5.6.4, «SHOW VARIABLES». После модификации стоп-листа перестройте ваши полнотекствые индексы. (Эта переменная введена в MySQL 4.0.10)

 

[_RVK_]

Royal Flash
Попробуй посмотреть на проблемму шире. Я не хочу расказывать про задачи, которые со временем дополняются и изменяются. В средних и больших проектах это так и есть, и рано или похдно, тебе придется предоставить пользователю возможность редактирования того, что ты не предполагал в первой версии.

Дальше скажу, что если твоему сайт не будет хватать места на обчном десятибаксовом хостинге,то, скорее всего, ты выделишь деньги из суммы предназначенное на покупку BMW M3, на то, что бы эти ламеры - таои админы, наконец пошевилили свои задницы и настроили свой сервак.

 

[sakon]

В ходе этого топика, на мой взгляд, опредилились 2 религиозных убеждения.
1. В базу информация передается as is (за исключением trim)
2. В базу класть обработанную информацию.
Почему религиозные? Потому, что и одна из сторон не привела внятную аргументацию в пользу того или иного способа хранения информации в базе. Вроде как он есть, но его никто не видел, поэтому в него надо просто верить (а раз никто не видел, то и появляются разные течения в религии). Для меня этой проблемы не существует, кидаю в базу as is "если бизнес-логикой не предусмотрено обратного" © svetasmirnova.
Кто то применяет к пришедшим данным, перед вставкой в базу htmlspecialchars только потому, что не до конца понимает, что эта функия предназначена для вывода информации. Он режет HTML в пришедшей информации потому, что ему никто не может объяснить почему этого делать ненадо. Про замену во входящей информации HTML на что то вроде ВВcode вообще говорить не хочется (на мой взгляд несусветная чушь).
А посему...
_RVK_
Полностью с тобой согласен насчет дополнительной ячейки (или таблицы) для инфы предназначеной для поиска (хотя эту информацию придется предварительно обрабатывать, очистка там и прочее, перед вставкой в базу , но этот случай как раз можно отнести к вышепреведенному копирайту Светы).
И из этого:
- Информация поступившая от пользователя, при необходимости проверяется (щит) на валидность и если все ОК кладется в базу как есть
- Информация пришедшая от пользователя обрабатывается (меч) перед выводом .

P.S.
Интересно - почему молчит Фанат...?

PSS

Все это большое IMHO

 

[Kirs]

svetasmirnova ты предлагаешь исключить из поиска такие слова как table, body, head, width, input и т.п.? Вот обрадуются англоязычные пользователи его сайта...

 

[baev]

Kirs, а чуть-чуть подумать?
И исключать из поиска, например, такие слова как '<table', '<body', '<head', 'width=', '<input'?