Зачем использовать filter_input если можно тот же результат получить меньшим кодом?

Question

[Алексей Коновалов]

Подскажите, для чего использовать вот такую строку?

$id = filter_input(INPUT_GET, 'id', FILTER_SANITIZE_NUMBER_INT);

Ведь проще сделать так, а результат тот же:
$id = intval($_GET['id'] ?? 0)

или так:

$id = isset($_GET['id']) ?  intval($_GET['id']) : null

Comments

[Максим Федоров]

в данном случае проще, в др случаях не проще

иногда можете посмтотреть примеры в доке

[Ипатьев]

Максим Федоров, ну прямо скажем, высосанный из пальца пример :)

[Ипатьев]

Алексей Коновалов вот видите, как важно делать адекватный заголовок? Люди никогда не читают сам вопрос, а читают только заголовок. И я в том числе :)
А в итоге вы получаете совсем не тот ответ, который хотели получить.

Answer 1

[SagePtr]

К примеру, в параметры $_GET или $_POST легко может попасть массив, если злоумышленник передаст его в виде url?id[]=1
Большинство начинающих разработчиков о такой возможности PHP даже и не в курсе и ожидают там гарантированно увидеть строку (если параметр определён).
В ситуации с intval это к ошибке не приведёт, intval приведёт неподходящие типы к 0 или 1, но в прочих ситуациях может сыграть плохую роль.

Comments

[Ипатьев]

И как это скажется на коде, который приведён в вопросе?

[SagePtr]

Роман Юрьевич Ипатьев, конкретно в данном коде работать будет и так. Ну, кроме странностей поведения, если массивы на входе будет воспринимать, как 1.

Answer 2

[Ипатьев]

Мне не нравится ни тот ни другой вариант.

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

В случае, если вместо числового id нам приходит вдруг массив, надо не молча его глотать и химичить с превращением в число, а сразу отвечать в репу 400-й ошибкой, не разводя сантименты.

Поэтому я бы взял какую-нибудь либу для валидации, вот первая же из гугля, https://github.com/rakit/validation
И нормально проверял входящие параметры.
В случае, если это пользовательский ввод, типа логина и пароля, то отдавать культурные ошибки
Если же это чисто внутренняя инфраструктура приложения, типа id из нашей же ссылки, то при наличии ошибок молча отдавал 400.

Comments

[Алексей Коновалов]

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

[Ипатьев]

Если же это чисто внутренняя инфраструктура приложения, типа id из нашей же ссылки, то при наличии ошибок молча отдавал 400.