Всем привет!!! Давно мучаюсь с обработкой данных полученных из глобальных массивов $_GET, $_POST, $_COOKIE, $_SESSION. Подскажите как обычно "очищаются" данные из этих массивов перед использованием? Как делаю я: 1. Есть класс, который "приводит" полученные данные к нужным мне стандартам, например Код (PHP): final class Clear { public static function clearVar($value, $case = false) { switch ($case) { # ---- Нижний регистр ---- case 1: $value = self::defaultMethod($value); $value = mb_convert_case($value, MB_CASE_LOWER); break; # ---- Первая буква каждого слова заглавная ---- case 2: $value = self::defaultMethod($value); $value = mb_convert_case($value, MB_CASE_TITLE); break; // И т.д. # ---- По умолчанию ---- default: $value = self::defaultMethod($value); break; # ---------------------- } return $value; } private static function defaultMethod($value) { $value = strip_tags($value); # Удаление HTML и PHP-тегов $value = htmlspecialchars($value); # Замена HTML тегов на спецсимволы $value = preg_replace(self::REG_001, ' ', $value); # Удаление дублирующихся пробелов $value = trim($value); # Удаление пробелов из конца и начала return $value; } } 2. В самом "начале" загрузки страницы index.php перебираю нужный массив, например $_POST Код (PHP): foreach ($_POST as $k => $v) { if (preg_match("/_([0-9]+)$/i", $k, $m)) $v = Clear::clearVar($v, $m[1]); else $v = Clear::clearVar($v); $_POST[$k] = $v; } И дальше уже "спокойно" использую $_POST. Т.е. если я хочу, чтобы например "имя пользователя" было в нижнем регистре, то в HTML я пишу: Код (Text): <input name="userName_1" /> А использую так: Код (PHP): Здравствуйте <?=$_POST['userName_1']?>, добро пожаловать в Личный кабинет.
У меня это есть в классе Clear и методе defaultMethod Вопрос немного не в этом. Добавлено спустя 16 минут 9 секунд: Вместо пункта "2" (в первом сообщении) я использую класс: Код (PHP): final class GlobalArray { public static function clear($a, $t) { static $keys; foreach ($a as $k => $v) { $keys[] = $k; if (is_array($v)) self::clear($v, $t); else { if (preg_match("/_([0-9]+)$/i", $k, $m)) $v = Clear::clearVar($v, $m[1]); else $v = Clear::clearVar($v); switch (count($keys)) { // Одномерный массив case 1: switch ($t) { case '_GET': $_GET[$keys[0]] = $v; case '_POST': $_POST[$keys[0]] = $v; case '_COOKIE': $_COOKIE[$keys[0]] = $v; case '_SESSION': $_SESSION[$keys[0]] = $v; } break; // Двухмерный массив case 2: switch ($t) { case '_GET': $_GET[$keys[0]][$keys[1]] = $v; case '_POST': $_POST[$keys[0]][$keys[1]] = $v; case '_COOKIE': $_COOKIE[$keys[0]][$keys[1]] = $v; case '_SESSION': $_SESSION[$keys[0]][$keys[1]] = $v; } break; // Трехмерный массив case 3: switch ($t) { case '_GET': $_GET[$keys[0]][$keys[1]][$keys[2]] = $v; case '_POST': $_POST[$keys[0]][$keys[1]][$keys[2]] = $v; case '_COOKIE': $_COOKIE[$keys[0]][$keys[1]][$keys[2]] = $v; case '_SESSION': $_SESSION[$keys[0]][$keys[1]][$keys[2]] = $v; } break; } $keys = array(); } } } } Который я использую так: Код (PHP): GlobalArray::clear($_GET, '_GET'); GlobalArray::clear($_POST, '_POST'); GlobalArray::clear($_COOKIE, '_COOKIE'); GlobalArray::clear($_SESSION, '_SESSION'); Проблема в том, что приходится "определять" какой именно массив я "очищаю". case '_GET', case '_POST'. Пробовал передавать массив по ссылке, но тогда "чистится" только одномерный массив. Пробовал использовать второй передаваемый параметр, как название массива, например: Код (PHP): $name = '_POST'; ${$name}[$keys[0]] = $v; Но так тоже "не прокатывает", т.к. это работает только с "новой" переменной, а массивы уже "создаются" заранее (до этого кода).
Ты приводишь данные к нужному тебе формату. В чем вопрос? Если только в этом, то ответ - никак. Чаще всего данные валидируются и обрабатываются. Суть первого заключается в проверке на соответствие формату. Если у тебя в логине разрешены только буквы, цифры и подчеркивание, ты проверяешь введенный логин и выводишь сообщение об ошибке, если он не соответствует формату. А не подстраиваешь его под формат. Если это не логин, а например, сообщение, то разумнее его обработать с помощью htmlspecialchars перед отображением (а не перед записью в базу), чтобы пользователи видели именно то, что вводят, а в базу сохранилось именно то, что ввел пользователь. А не удалять теги и неподходящие символы. Для защиты нужны всего две функции: htmlspecialchars (от XSS) и mysql_real_escape_string (или аналогичная, от инъекций).
А как тогда проверять скажем цену товара? Пользователь вводит "1500,00", а мне нужно (для записи в таблицу) "1500.00", т.е. если есть запятые, то заменить их на точки. И допустим у меня 2 поля: - цена товара - цена товара со скидкой И получается мне нужно написать 2 валидатора с одним и тем же кодом по замене запятых на точки. Один валидатор не прокатит, т.к. в одном мне нужно в случае неверного ввода сказать, "введи правильно цену товара", а в другом "введи правильно цену товара со скидкой", а таких полей может быть не 2шт. Добавлено спустя 9 минут 11 секунд: А так я заранее во всех "ценах" в инпуте допишу скажем "название_5", т.е. "цена_5", "цена_со_скидкой_5" и во всех их "заранее" перед валидацией заменю запятые на точки, удалю пробелы слева и справа и скажем приведу к типу float. И в валидаторе нужно будет проверить только мин. длину, макс. длину.
Конкретно в этой ситуации можно использовать Код (Text): <input type="number" steps="0.01" name="price"> хотя в это поле можно вписать запятую, при отправке будет точка. Валидация так же снижает риск ошибки. Пользователь мог перепутать поля и ввести не те данные. Если ты молча отфильтруешь их, сохранится ерунда. Добавлено спустя 1 минуту 2 секунды: Использование специальных типов полей не избавляет от необходимости валидации. Они предназначены, чтобы пользователю было легче ввести данные правильно. Добавлено спустя 2 минуты 23 секунды: Еще в HTML 5 можно валидировать с помощью регулярки прямо в HTML, без скриптов и отправки формы. http://www.htmlgoodies.com/html5/markup/telerik-takes-cross ... lease.html
Согласен, можно поступить так. А что если у пользователя IE7? А что если он "злоумышленник" и отправит исправленную форму где не будет type="number" steps="0.01"? Вот еще пример: с названиями или заголовками или подзаголовками без разницы. У каждого из них будет свой валидатор (ну не совсем у каждого конечно). И пользователь написал HTML тэги, которые мне не нужны там совсем или "случайно" поставил кучу пробелов (пробел заело или скопировал текст из таблицы) какой здесь будет валидатор? Проверить мин. и макс. длину? А как же пробелы? Или во всех валидаторах писать один и тот же код по удалению пробелов, тэгов или еще чего? Я привожу такие примеры так как, пример с "логином" очень простой (хотя опять же и в нем могут быть пробелы). Пользователь скопировал свой логин из таблицы .xls (хранит он их там) и вставил. Валидатор ему скажет: "Не верно введен логин" или даже так "Не верно введены логин или пароль". А введено все верно, всего лишь пробел в конце один (незаметный) и пользователь думает, логин верный, ну тогда с паролем косяк получается... Понимаете о чем я? Тогда и в валидаторе логина нужно опять же в 10-ый или 20-ый раз как и в других валидаторах удалить пробелы слева и справа, удалить тэги (мало ли от куда он его скопировал). Так называемая "очистка" не обязательно должна "обезопасить" данные, но и помочь пользователю и "исправить" случайные его ошибки при вводе. Добавлено спустя 11 минут 11 секунд: Кстати "хорошее", вернее более подходящее слово "фильтр", вместо чистки. Ерунда кстати тоже сохраниться не может, например если мне в этой переменной нужно число, то максимум, что я получу, так это "0", так как после фильтрации "по умолчанию" Clear::defaultMethod() я умножу эти данные на 1 или приведу их к типу integer. И уже 0 не пройдет валидацию и не будет записан в таблицу. Кстати я не писал, что НЕ использую валидации. Использую, но после фильтрации.
т.е. в любом случае надо проверять на сервере. значит надо ему сказать, что скобки < > запрещены. Хотя если у тебя не HTML-редактор, то это и не теги вовсе, а просто текст, который в любом случае перед отображением надо прогонять через htmlspecialchars, чтобы где-нибудь разметка не поехала, из-за попадания кавычки в alt картинки. А после htmlspecialchars теги работать не будут, так зачем их вырезать? Пускай пользователь видит то, что ввёл. на счет trim, пожалуй, соглашусь. А вот то, что ноль - не число, это редкий случай. И еще php делает так: Код (Text): $a = '33 коровы'; echo $a * 1; // 33
Верно Не соглашусь. Зачем ему эта "лишняя" информация? Пользователь добавляет новый товар например, скопировал его название от куда нибудь, вставил в поле. Предположим, что там были тэги (или еще то, что там быть не должно), зачем ему про это говорить? Он нажимает кнопку "Сохранить" и видит: "Такие то символы запрещены (и далее идет их перечисление)". Он удаляет символы, снова нажимает кнопку и тут опять: "Такие то символы запрещены" (ну не увидел он несколько))). Находит их и удаляет и опять: "Вы все еще не все запрещенные символы удалили, типа смотрите ВНИМАТЕЛЬНЕЕ". Что после этого он подумает не трудно догадаться... Проще всю эту "рутинную" работу сделать ЗА него. PHP ведь не "влом". Где они нужны, там их никто не собирается удалять. Просто добавляем в switch новый кейс, у которого номер будет (какой там следующий?), пускай 8. И текстовое поле называем "название_8". В кейсе будет htmlspecialchars, удаление двойных и более пробелов и trim (куда же без него). Метод defaultMethod использоваться не будет. И теперь во всех полях, где нужно сохранить тэги к названию будем дописывать "_8". Да не редкий. Опять же "цена товара". Вот захотел я чтобы можно было добавлять товары с ценой. Валидатору нужно будет проверить: - не пустое ли поле? - число больше нуля? И если пользователь введет текст, то до валидатора "дойдет" только 0. А если "33 коровы", то 33. Все правильно делает php, мы получили число, что и хотели для поля цены товара.