Хранить объекты html в базе данных? Или конвертировать при восстановлении?

Быстрый вопрос: лучше ли вызывать htmlentities() (или htmlspecialchars()) до или после вставки данных в базу данных?

До: Новая длинная строка заставит меня изменить базу данных для хранения более длинных значений в поле. (maxlength="800" может измениться на строку 804 char)

После: Это потребует намного большей обработки сервера, и сотни вызовов htmlspecialchars() могут быть сделаны при каждой загрузке страницы или загрузке AJAX.

SOOO. Будет ли преобразование, когда результаты будут получены, замедлит мой код? Должен ли я изменить БД?

ОТВЕТЫ

Ответ 1

Я бы рекомендовал хранить наиболее сырую форму данных в базе данных. Это дает вам максимальную гибкость при выборе способа и способа вывода этих данных.

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

Ответ 2

У меня нет опыта работы с php, но обычно я всегда конвертирую или бегу ближе к выходу. Вы не знаете, когда ваши требования к выпуску будут изменены, например, вы можете захотеть выплескивать данные в виде XML или массивов JSON и таким образом избегать HTML, а затем хранить средства, которые ограничены использованием данных только как HTML.

Ответ 3

В веб-приложении php/MySQL данные передаются двумя способами.

База данных → язык сценариев (php) → вывод HTML → браузер → экран а также Keyboard- > browser- > $_POST → php → SQL statement → database.

Данные определяются как все, предоставленные пользователем.

ВСЕГДА ВСЕГДА ВСЕГДА....

A) обрабатывать данные через mysql_real_escape_string при перемещении в SQL-запрос и

B) обрабатывать данные через htmlspecialchars, когда вы перемещаете его в вывод HTML.

Это защитит вас от SQL-инъекций и позволит отображать символы и объекты html должным образом (если вам не удастся забыть одно место, а затем вы открыли отверстие для безопасности).

Я упоминал, что это нужно делать для каждого отдельного фрагмента данных, который любой пользователь мог бы затронуть, изменить или предоставить через script?

p.s. По соображениям производительности используйте кодировку UTF-8 всюду.

Ответ 4

Лучше всего хранить текст как необработанный и кодировать его по мере необходимости, честно говоря, вам всегда нужно htmlencode ваши данные в любом случае, когда вы выводите его на страницу wbe, чтобы предотвратить взлом XSS.

Вы не должны кодировать данные перед тем, как поместить их в базу данных. Основная причина:

  • Если такие данные находятся рядом с пределом размера столбца, скажем, 32 символа, если заголовок был "Стив и Фред бла-бла", тогда вы можете пройти через этот столбец, потому что 1 char и становится 5 char и усилитель;
  • Вы предполагаете, что данные всегда будут отображаться на веб-странице, в будущем вы никогда не знаете, где будете искать данные, и вы можете не захотеть ее закодировать, теперь вы должны ее расшифровать, и это возможно может не иметь доступа к функции декодирования PHP

Ответ 5

Это способ ремесленника "дважды измерять, оптимизировать один раз".

Ответ 6

Если вам не нужна высокая производительность для вашего сайта, сохраните его как необработанные данные, и когда вы выведете его, сделайте то, что хотите.
Если вам нужна производительность, подумайте о ее сохранении дважды: необработанные данные, чтобы делать то, что вы хотите, и другое поле с отфильтрованными данными. Это можно считать избыточным, но CPU стоит дорого, а хранилище данных действительно дешево.

Ответ 7

Самый простой способ - хранить данные "как есть", а затем преобразовывать их в htmlentities везде, где это необходимо.

Самое безопасное решение - это отфильтровать данные до того, как они войдут в базу данных, поскольку это предотвратит возможные атаки на ваш сервер и базу данных из-за отсутствия реализации безопасности, а затем преобразует их, как вам нужно, когда это необходимо. Также, если вы используете PDO, это автоматически произойдет для вас с помощью подготовленных операторов.

http://php.net/PDO

Ответ 8

Недавно мы обсуждали эту дискуссию. Мы решили сохранить экранированные значения в базе данных, потому что раньше (когда мы хранили его без сохранения) были угловые случаи, когда данные отображались без экранирования. Это может привести к XSS. Поэтому мы решили сохранить его сбежать, чтобы быть в безопасности, и если вы хотите, чтобы он не был побежден, вы должны сами выполнить эту работу.

Изменить: Итак, всем, кто не согласен, позвольте мне добавить предысторию для моего дела. Скажем, вы работаете в команде из 50 человек... и данные из базы данных не гарантируются HTML-кодировкой на выходе - там нет встроенного механизма, поэтому разработчику приходится писать код сделать это. И эти данные отображаются повсеместно, поэтому он не проходит через один код разработчика, через который проходит 30 - большинство из них не имеют понятия об этих данных (или что они могут даже содержать угловые скобки, что редко) и просто хотят получить его показан на странице, перейдите и забудьте об этом.

Вы все еще считаете, что лучше помещать данные в HTML в базу данных и полагаться на случайных людей, которые не являются - вы должны делать что-то правильно? Потому что, честно говоря, хотя это, конечно, может показаться не теплой-нечеткой-наилучшей практикой, я предпочитаю сбой закрыться (это означает, что когда данные поступают в Word Doc, это выглядит как Value & lt; Stock, а не Value < Stock), а не открыто (поэтому Word Doc выглядит правильно без какой-либо работы, но некоторый угол платформы может/вероятно, уязвим для XSS). У вас не может быть обоих.