Комментарии 8
В коде видно, что функция распознает значение по типу. И если это строка — то мы смело можем триммить по краям лишний пробел, переносы строки, перенос каретки или табуляцию,
А где в теле функции распознавание именно строки?
if elem.Kind() == reflect.Struct {
...
}
Здесь распознаем на входе именно структуру. А не какой-нибудь bytes.Buffer, к примеру. А где распознавание строк?
EDIT. А, стоп, нашел. Это в предыдущей функции handleField()
Спасибо, полезно. Похоже на "санизацию" входных данных.
Какие-то странные кейсы. Пользователь в принципе не должен самостоятельно вводить JWT-токен или UUID, а при отправке на сервер данные должны быть корректными.
Даже если исправлять их на стороне сервера, что мешает сделать как-то так:
UUID.parse(strings.TrimSpace(req.Id))Далеко не всегда требуется подобная санитизация, тем более глобально. Лучше обрезать потенциальные лишние символы там, где это нужно, чтобы потом не напарываться на проблемы типа "почему в тексте обрезались пробелы в начале?"
Спасибо за комментарий.
На самом деле, есть кейсы когда jwt токены люди генерируют и руками копируют еще на этапе тестирования public api. И уже этот кейс может складывать у пользователей начальное впечатление - вот тут и клиентоцентричность.
В частности для jwt, или еще как пример, для поля имя пользователя или пароль - из моей практики, люди часто копируют лишние символы (особенно если хранят их в блокноте или копируют из почты вместе с переносом строки).
А когда парольные политики изначально не подразумевают перенос строки и табуляцию в пароле - зачем пользователю кидать ошибку? Пользователь сталкивается с непониманием. Статья, скорее об этом. А интерцепторы - как способ.
Абсолютно согласен, что такой подход не работает для всех полей - именно поэтому в статье, в коде реализации, даем право выбрать имя поля которое собираемся модифицировать.
Тут можно много примеров за и против привести. Но важно, то - что у если прямо сейчас в проекте 100 контроллеров которые кидают эту бессмысленную ошибку при валидации uuid - в разы проще написать интерцептор (с привязкой к конкретному полю, если нужно), чем править логику 100 контроллеров - об этом описано во «втором способе»
Триминг - здесь в статье один из примеров (логика, на самом деле может быть сложнее), что поля на самом деле можно санитизировать в одном едином месте и для тех данных, где точно никогда не будет пробелов и других посторонних символов.
Абсолютно непонятно, как вообще ввод пользователем UUID и JWT-токена изначально могли быть клиентоориентированными и если необходимо почистить данные, почему бы не добавить пару строк кода в тот же обработчик?
Ну а если это примеры, то они подобраны не к месту, скорее усложнили понимание
Клиентоцентричность с точки зрения Go-разработчика и причем тут рефлексия