-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Что делать с данными, приходящими от пользователя?
- Автор темы _RVK_
- Дата начала
- Статус
white phoenix
Новичок
Честно говоря, я не очень понимаю откуда столько флейма в теме, всё ведь очень очень просто и понятно, лично я, давным давно, путем размышлений на этот счет сделал правильные выводы, вот они. При отправке формы, нужно проверить поля на формат: длину, допустимые символы, структуру (например, при вводе email), обычно для этого достаточно одного регулярного выражение на каждое поле, если есть какие-то ошибки, то выводим нечто вроде "Обнаружены ошибки:", перечисляем их и снова показываем форму, уже заполненую прислаными данными, т.е. например для text - value=\"".htmlspecialchars($variable)."\", htmlspecialchars позволяет показывать специальные HTML-символы, заменяя их на литералы. Если ошибок нет, то в БД складываем каждое поле как оно есть, бороться с SQL-инъекциями следует уже на заключительной стадии делая [m]mysql_real_escape_string[/m] непосредственно при составлении запроса к СУБД, а не на стадии проверки переменных.
При выводе из базы нужно делать сначала [m]htmlspecialchars[/m], а потом, если потребуется, парсинг BB-кодов и прочего добра.
Эта схема хороша со всех сторон, во-первых она безопасна, во-вторых позволяет корректно редактировать поля, производить поиск (об этом ниже), и т.д. Хранить в БД закодированные поля очень глубо т.к. это не позволит делать сложную выборку (и по иск в том числе). По поводу поиска: если в БД довольно большие объемы информации (особенно текстовой), то целосообразно сделать отдельную таблицу и в ней хранить данные для поиска, обычно это ключевые слова, и она имеет строение навскидку:
`id` - идент. материала которому соответствуют ключевые слова, например, postid на форуме.
`words`- сами ключевые слова.
После того как мы получаем список ID найденных постов, получаем их полный текст из таблицы с постами, и выводим красиво результат. Этот подход хорош тем что мы избавляемся от приличных затрат производительности при поиске, т.к. если мы выбираем из таблицы с постами, а не с ключевыми словами, нам придется обходить каким-то образом тэги, BB-коды и т.д., и LIKE нам тут явно не товарищ.©
При выводе из базы нужно делать сначала [m]htmlspecialchars[/m], а потом, если потребуется, парсинг BB-кодов и прочего добра.
Эта схема хороша со всех сторон, во-первых она безопасна, во-вторых позволяет корректно редактировать поля, производить поиск (об этом ниже), и т.д. Хранить в БД закодированные поля очень глубо т.к. это не позволит делать сложную выборку (и по иск в том числе). По поводу поиска: если в БД довольно большие объемы информации (особенно текстовой), то целосообразно сделать отдельную таблицу и в ней хранить данные для поиска, обычно это ключевые слова, и она имеет строение навскидку:
`id` - идент. материала которому соответствуют ключевые слова, например, postid на форуме.
`words`- сами ключевые слова.
После того как мы получаем список ID найденных постов, получаем их полный текст из таблицы с постами, и выводим красиво результат. Этот подход хорош тем что мы избавляемся от приличных затрат производительности при поиске, т.к. если мы выбираем из таблицы с постами, а не с ключевыми словами, нам придется обходить каким-то образом тэги, BB-коды и т.д., и LIKE нам тут явно не товарищ.©
kvf77
Red Devil
sakon
лично я помоему приводил и гораздо более внятную, чем _RVK_, а _RVK_, как я и полагал, вовсе не спрашивал мнения, достаточно прочитать его "феерическое" (с) Фанат заключение про "Старичков"
В целом, Как я говорил Роме, считаю топик вредным, потому что он насаждает не то чтобы неправильный взгляд на вещи, а он насаждает КАТЕГОРИЧНЫЙ взгляд Ромы на хранения данных, новичек, для которых он якобы затеял этот спор, это собъет с толку и не даст им (из моего опыта) шанса учиться и выбирать что действительно правильно.
-~{}~ 18.12.05 12:33:
sakon
Фанат правильно молчит
потому что тема гнилая больно ух
лично я помоему приводил и гораздо более внятную, чем _RVK_, а _RVK_, как я и полагал, вовсе не спрашивал мнения, достаточно прочитать его "феерическое" (с) Фанат заключение про "Старичков"
В целом, Как я говорил Роме, считаю топик вредным, потому что он насаждает не то чтобы неправильный взгляд на вещи, а он насаждает КАТЕГОРИЧНЫЙ взгляд Ромы на хранения данных, новичек, для которых он якобы затеял этот спор, это собъет с толку и не даст им (из моего опыта) шанса учиться и выбирать что действительно правильно.
-~{}~ 18.12.05 12:33:
sakon
Фанат правильно молчит
потому что тема гнилая больно ухwhite phoenix
Новичок
sakon
Что значит до или после? В базу попадает непрошедший через htmlspecialchars текст.
Что значит до или после? В базу попадает непрошедший через htmlspecialchars текст.
master_x
Pitavale XXI wieku
sakon
перечитываем пост белого феникса еще раз.
Вообще-то правильные тезисы были сформулированны езе на третьей или четвертой странице, теперь каждый приходит и просто пересказывает, при этом немного искажая смысл.
kvf77
Если бы тема была гнилой, ее бы уже давно закрыли (это намек).
перечитываем пост белого феникса еще раз.
Вообще-то правильные тезисы были сформулированны езе на третьей или четвертой странице, теперь каждый приходит и просто пересказывает, при этом немного искажая смысл.
kvf77
Если бы тема была гнилой, ее бы уже давно закрыли (это намек).
white phoenix
Новичок
Sakon
htmlspecialchars в value это для броузера, а не для БД, по submit'у формы придут нормальные значения не прошедшие htmlspecialchars.
htmlspecialchars в value это для броузера, а не для БД, по submit'у формы придут нормальные значения не прошедшие htmlspecialchars.
white phoenix
Новичок
master_x
> теперь каждый приходит и просто пересказывает, при этом немного искажая смысл.
не согласен, в теме много было высказано противоречивого.
> теперь каждый приходит и просто пересказывает, при этом немного искажая смысл.
не согласен, в теме много было высказано противоречивого.
Royal Flash
-=MaestrO=-
baev
Вот если чуть-чуть подумать, то можно сразу решить, что вариант для полнотекстового поиска со стоп словами вообще не подходит.
Для решения проблемы не нахождения тегов и т.д. я вижу 2 варианта:
1. Использование доп. таблицы, в которй будут храниться чистые, без тегов и т.д. данные - только текст. В этом случае проблем с полнотекстовым поиском не будет, хотя вариант ну уж очень не красивый в плане нерацианального использования дискового пространства.
2. Использование доп. таблицы, в которй будут храниться собственные индексы, не включающие Html и т.д. Этот вариант, по моему мнению, наиболее предпочтителен, хотя при его использовании Fulltext не понадобится...
Вот если чуть-чуть подумать, то можно сразу решить, что вариант для полнотекстового поиска со стоп словами вообще не подходит.
Fulltext находит только слова "table", например, но ни как не "<table". Читайте документацию. Исключить вообще названия тегов тоже нет резона, как правильно вы заметили, что англоязычный поиск от этого сильно пострадает.
Для решения проблемы не нахождения тегов и т.д. я вижу 2 варианта:
1. Использование доп. таблицы, в которй будут храниться чистые, без тегов и т.д. данные - только текст. В этом случае проблем с полнотекстовым поиском не будет, хотя вариант ну уж очень не красивый в плане нерацианального использования дискового пространства.
2. Использование доп. таблицы, в которй будут храниться собственные индексы, не включающие Html и т.д. Этот вариант, по моему мнению, наиболее предпочтителен, хотя при его использовании Fulltext не понадобится...
zarus
Хитрожопый макак
Я не понимаю, почему функционал префильтрации данных _RVK_ и компания сводят к функции htmlspecialchars? При этом соглашаясь, что данные нужно обрабатывать до ввода в базу (валидация). Просто подменяют общий термин единственной специфической функцией, которая предназначена для того, чтобы не "ломать" html-разметку. И после этого они делают вывод, что правы...
В общем, и правда тема гнилая. Новичков она только в заблуждение вводит.
В общем, и правда тема гнилая. Новичков она только в заблуждение вводит.
BeGe
Вождь Апачей, блин (c)
1. В базе хранишь всё как ввёл пользователь.
2. При хранении первичных данных, потом ты можешь изменять их как тебе захочется, хоть вырезать весь html, хоть оставить - мало ли что. (меч)
3. Хранение первичных данных от пользователя - защитить структуру базы (щит), проверить данные на валидацию для базы данных.
Если тебя не устраивают такие принципы - проще купить новое железо, чем тут что-то менять.
2. При хранении первичных данных, потом ты можешь изменять их как тебе захочется, хоть вырезать весь html, хоть оставить - мало ли что. (меч)
3. Хранение первичных данных от пользователя - защитить структуру базы (щит), проверить данные на валидацию для базы данных.
Если тебя не устраивают такие принципы - проще купить новое железо, чем тут что-то менять.
ForJest
- свежая кровь
Признаюсь я не очень внимательно прочитал топик .
Хочу сделать несколько замечаний
1. Исходная постановка вопроса подразумевает что "данные" введённые пользователем только затем и нужны, чтобы их потом показывать.
Это, с моей точки зрения довольно однобокий подход, в целом продиктованный, понятное дело популярностью Database Driven Applications.
Т.е. среднестатистическое сознание воспринимает БД как промежуточное, временное хранилище для ввода пользователя.
Я успешно применял довольно простой подход.
- Храним ввод пользователя, вплоть до хранения сериализованного $_POST массива, очень помогает при сложносоставных структурах данных
- Храним данные для обработки, вычлененные из этого входного потока. Например слова для поиска, количество может там или числа какие-нибудь.
Т.е. мы получаем выгоду от хранения ввода пользователя неизменённым - имеем два представления - изменённое для наших нужд и представление, в котором данными оперирует пользователь.
При необходимости он может отредактировать их имеено в том виде, в котором их ввёл. Но то что получится из этих данных, то как обработает их система может сильно отличаться от того что ввёл пользователь.
---------------------
Для примитивного понимания данный подход полностью снимает все вопросы. Можно хранить два или три представления, допустим
- то что ввёл пользователь
- то что нужно выводить
- данные для поиска. Это могут быть дополнительные колонки, на которые, допустим мы делаем индекс. Или хэши текста, контрольные суммы - в целом это вычисляемые поля.
---------------------------
2. Проверки. Если система должна оперировать с данными, т.е. не просто их сохранять-выводить, а что-то с ними делать, производить действия, то проверки жизненно необходимы.
Хороший пример - email. Если его сохранить "как есть" это никак не поможет чтобы отсылать по нему письма. Поэтому данные, над которыми производятся действия, обработка данных необходимо проверять.
- Если не проверить их сразу, то что делать, когда система попадёт в исключительную ситуацию, позже?
- Как уведомить потом пользователя, о том что его данные приводят к исключительной ситуации?
- Как сохранение в первоначальном виде помогает или не помогает избежать этой ситуации?
Проверки и "вырезания" продиктованы надобностями системы обработки данных, а не пользователя. Поэтому нет необходимости заботится о сохранении их в первоначальном виде, т.к. они нужны не пользователю. Они нужны системе.
---------------------
Поэтому, я предлагаю не мешать всё в кучу и задуматься об интересной концепции
"Данные для промежуточного хранения" - сообщения в гостевухах, странички с текстом в CMS
и
"Данные для обработки" - emails, количество денег, для снятия со счёта, номер кредитки, возраст или дата рождения. Те, кто дочитал до этого места могут вступить со мной в дискуссию. Те кто не дочитал - сам себе злой буратино.
---------------------
Далее. Данные имеющие большой объём, и лишённые какой-либо чётко означенной структуры обычно не подвергаются обработке. Но это уже маленький довесок, не относящийся к теме беседы.
.Хочу сделать несколько замечаний
1. Исходная постановка вопроса подразумевает что "данные" введённые пользователем только затем и нужны, чтобы их потом показывать.
Это, с моей точки зрения довольно однобокий подход, в целом продиктованный, понятное дело популярностью Database Driven Applications.
Т.е. среднестатистическое сознание воспринимает БД как промежуточное, временное хранилище для ввода пользователя.
Я успешно применял довольно простой подход.
- Храним ввод пользователя, вплоть до хранения сериализованного $_POST массива, очень помогает при сложносоставных структурах данных
- Храним данные для обработки, вычлененные из этого входного потока. Например слова для поиска, количество может там или числа какие-нибудь.
Т.е. мы получаем выгоду от хранения ввода пользователя неизменённым - имеем два представления - изменённое для наших нужд и представление, в котором данными оперирует пользователь.
При необходимости он может отредактировать их имеено в том виде, в котором их ввёл. Но то что получится из этих данных, то как обработает их система может сильно отличаться от того что ввёл пользователь.
---------------------
Для примитивного понимания данный подход полностью снимает все вопросы. Можно хранить два или три представления, допустим
- то что ввёл пользователь
- то что нужно выводить
- данные для поиска. Это могут быть дополнительные колонки, на которые, допустим мы делаем индекс. Или хэши текста, контрольные суммы - в целом это вычисляемые поля.
---------------------------
2. Проверки. Если система должна оперировать с данными, т.е. не просто их сохранять-выводить, а что-то с ними делать, производить действия, то проверки жизненно необходимы.
Хороший пример - email. Если его сохранить "как есть" это никак не поможет чтобы отсылать по нему письма. Поэтому данные, над которыми производятся действия, обработка данных необходимо проверять.
- Если не проверить их сразу, то что делать, когда система попадёт в исключительную ситуацию, позже?
- Как уведомить потом пользователя, о том что его данные приводят к исключительной ситуации?
- Как сохранение в первоначальном виде помогает или не помогает избежать этой ситуации?
Проверки и "вырезания" продиктованы надобностями системы обработки данных, а не пользователя. Поэтому нет необходимости заботится о сохранении их в первоначальном виде, т.к. они нужны не пользователю. Они нужны системе.
---------------------
Поэтому, я предлагаю не мешать всё в кучу и задуматься об интересной концепции
"Данные для промежуточного хранения" - сообщения в гостевухах, странички с текстом в CMS
и
"Данные для обработки" - emails, количество денег, для снятия со счёта, номер кредитки, возраст или дата рождения. Те, кто дочитал до этого места могут вступить со мной в дискуссию. Те кто не дочитал - сам себе злой буратино
.---------------------
Далее. Данные имеющие большой объём, и лишённые какой-либо чётко означенной структуры обычно не подвергаются обработке
. Но это уже маленький довесок, не относящийся к теме беседы.- Статус