Я нашел здесь этот фрагмент кода: http://php.net/manual/de/reserved.variables.get.php
Хотите использовать его, чтобы сделать мой код более безопасным. Я использую довольно много $ _GET var в моем проекте.
Пожалуйста, по возможности я хотел бы, чтобы вы, профессионалы, посмотрели и посмотрели, может ли этот фрагмент кода быть улучшен или возникнут проблемы.
Существует разумный способ защиты ввода $ _GET от вредоносных инъекций и параметров для вставки значений по умолчанию:
<?php // Smart GET function public function GET($name=NULL, $value=false, $option="default") { $option=false; // Old version depricated part $content=(!empty($_GET[$name]) ? trim($_GET[$name]) (!empty($value) && !is_array($value) ? trim($value) : false)); if(is_numeric($content)) return preg_replace("@([^0-9])@Ui", "", $content); else if(is_bool($content)) return ($content?true:false); else if(is_float($content)) return preg_replace("@([^0-9\,\.\+\-])@Ui", "", $content); else if(is_string($content)) { if(filter_var ($content, FILTER_VALIDATE_URL)) return $content; else if(filter_var ($content, FILTER_VALIDATE_EMAIL)) return $content; else if(filter_var ($content, FILTER_VALIDATE_IP)) return $content; else if(filter_var ($content, FILTER_VALIDATE_FLOAT)) return $content; else return preg_replace("@([^a-zA-Z0-9\+\-\_\*\@\$\!\;\.\?\#\:\=\%\/\ ]+)@Ui", "", $content); } else false; } /* DEFAULT: $_GET['page']; SMART: GET('page'); // return value or false if is null or bad input */ ?> Источник: http://php.net/manual/de/reserved.variables.get.php
Идея старая и часто реализуется. Я лично предпочитаю вариант, где вы также указываете ожидаемый тип аргумента. Без этого я не вижу смысла в подходе, так как функция может реагировать только на то, что она получает.
Возьмем, например, пример «is_bool». Это не имеет никакого смысла вообще, как это реализовано сейчас. php никогда не будет содержать boolean здесь, он всегда будет интерпретировать аргумент get как строки с содержимым «false» или «true», если указано, или 0 и 1 или даже пустую строку. Поэтому это условие никогда не будет выполнено.
Возьмите случай «is_numeric» в качестве другого примера. Конечно, можно преобразовать строковую переменную в чистый числовой тип. Но какова идея замены на основе регулярных выражений? Если содержимое приводит к true как возвращаемое значение вызова is_numeric() , то там, безусловно, есть только числа. По определению. Это предполагает, что на самом деле это означало is_int() , поскольку в противном случае ветка состояния блокировала бы две следующие, которые вообще не имеют никакого смысла.
То, что я пропустил здесь, – это явное преобразование. Почему все усилия, если вы тогда не конвертируете в чистый тип переменной?
Это будет отличаться, если вы укажете ожидаемый тип функции:
// returns a boolean $isSomeFlagSet = GET('bool_flag', 'bool'); // returns an integer or throws an exception $numberOfHits = GET('number_of_hits', 'int'); // returns a string, maybe trimmed for convenience $userName = GET('user_name', 'string');
Вы даже расширяете это до не встроенных типов, которые добавляют к его значению:
// returns a string which is guaranteed to be a valid url $baseUrl = GET('base_url', 'url'); // returns maybe a two char language code (eg'en') or throws an exception $userLang = GET('lang', 'langcode'); // you could add a type 'json' which returns an array from a json get parameter $priceMatrix = GET('prices', 'json');
В этом случае проверка действительности действительно имеет смысл, поскольку она может четко решить, имеет ли смысл преобразование предоставленной строки. И он может выполнять явное и ожидаемое преобразование, чтобы после вызова этой функции у вас был гарантированный тип переменной.