Как правильно валидировать сырые параметры запроса в Symfony?

Question

[Daria Motorina]

Использую Symfony 5.0.

Понимаю, что ухожу сильно не туда в попытке задать валидацию для опционального GET параметра.
Нужно валидировать, что параметр param может иметь только true|false значение.
Сейчас у меня взаимоисключающие параграфы в коде - получение GET параметра и приведение его в тип bool нивелирует валидацию, а сырой GET-параметр имеет тип string, а не bool и поэтому валидация не работает как предполагалось.

Наверняка есть более чистый способ, но поиски не дают результата. Подскажите подход или ссылку на пример, пожалуйста.

Запрос: GET /neo/fastest?hazardous=true
Код:

/**
     * @Route("/neo/fastest", name="neo_fastest", methods={"GET"})
     */
    public function getFastestNearEarthObject(Request $request)
    {
        $constraints = new Collection([
            'hazardous' => [new Optional(new Type(['type' => 'boolean']))],
        ]);

        $errors = $this->validate($request->get('hazardous', false), $constraints);

        if ($errors) {
            return $this->json($errors, 400);
        }

        $isHazardous = filter_var($request->get('hazardous', false), FILTER_VALIDATE_BOOLEAN);
        //other code
   }

    /**
     * @param $value
     * @param $constraints
     *
     * @return array|void
     */
    protected function validate($value, $constraints)
    {
        $validator = Validation::createValidator();
        $violations = $validator->validate($value, $constraints);
        $messages = [];

        if (0 === count($violations)) {
            return;
        }

        foreach ($violations as $violation) {
            /* @var ConstraintViolation $violation */
            $messages[] = $violation->getMessage();
        }

        return $messages;
    }

Comments

[padlyuck]

https://symfony.com/doc/4.2/routing.html#routing-r...
https://symfony.com/doc/current/routing.html

/**
     * @Route("/neo/fastest/{hazardous}", name="neo_fastest", defaults={"hazardous"="0"}, requirements={"hazardous"="0|1"})
     */
    public function getFastestNearEarthObject(bool $hazardous)
    {
        // ...
    }

попробуйте так. Не уверен на счет кавычек для значения в defaults.

[BoShurik]

Как правильно фильтровать и мапить данные при реализации API на Symfony4? - вот этот вариант не подходит? Для GET запроса брать данные не из getContent, а из query->all()

[Daria Motorina]

padlyuck, спасибо, но это немного не то) В примере используется плейсхолдер для фиксированного параметра, а у меня сырой гет параметр, т.е. /url?param=value, а не /url/param, requirements и defaults не работают для него

[padlyuck]

Daria Motorina, не заметил)) тогда попробуйте так

$constraints = new Collection(
            [
                'hazardous' => [
                    new Optional(new Type(['type' => 'boolean'])),
                ],
            ]
        );

        $errors = $this->validate(['hazardous'=>$request->get('hazardous', false)], $constraints);

        if ($errors) {
            return $this->json($errors, 400);
        }

        $isHazardous = filter_var($request->get('hazardous', false), FILTER_VALIDATE_BOOLEAN);
        dump($isHazardous);

Хотя вариант BoShurik выглядит лучше кмк.

[Daria Motorina]

BoShurik, padlyuck спасибо)
Вариант с ModelResolver выглядит классно и точно пригодится в будущем, пока попробую приспособить к своему примеру

Answer 1

[Андрей Ждановских]

$isHazardous = $request->query->getBoolean('hazardous');

Будет true если передано "true" или 1, и false если "false" или 0.

Comments

[BoShurik]

А если передано foobar нам надо выкинуть 400

[Daria Motorina]

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

[Андрей Ждановских]

Ну хорошо, что в таком случае, означает «невалидный параметр»? Как по мне, так всё просто — всё, что не null и не false — то true. И я не могу вот так сходу сообразить, в чем проблема такого подхода.

[Daria Motorina]

Андрей Ждановских, клиент не должен слать данные, которые сервер не ожидает, и должен получать 400 в ответ в случае если нарушает формат данных. /endpoint?param=123 будет воспринято как булевый true, но это невалидные данные

[Андрей Ждановских]

Не вижу, если честно, причин, почему так должно быть. Но вероятно, они есть, и поэтому я не могу предложить решение, к сожалению,