Страницы

Поиск по вопросам

четверг, 29 ноября 2018 г.

Нестандартное (для меня) поведение параметров в контролере asp.net core

Когда-то в Web Api 2 я мог написать такой action:
public class INP { public string value { get; set; } } public string Post(INP con) { return con.value; }
и все отлично работало как с ContentType: application/x-www-form-urlencoded отправленным от клиента, так и с ContentType: application/json
Однако, в asp.net core все не так просто: с вышеприведенным кодом ContentType: application/x-www-form-urlencoded работает, а вот ContentType: application/json оставляет мне просто null в коде. Если обрамлять параметр атрибутом [FromBody], то ситуация меняется: с ContentType: application/json все отлично, а вот с ContentType: application/x-www-form-urlencoded мне вовсе приходит ответ вида 415 Unsupported Media Type
Итак, сам вопрос: как в asp.net core написать action, который бы принимал мне параметр разных ContentType'ов, как это было в Web Api 2? И почему поведение изменилось?


Ответ

Этот вопрос можно решить таким путем: нужно создать две разные Action method-ы, которые смогут специфически байндить данные необходимые для отправки, а затем делегировать обработку вызовов к общему методу.
Например:
public class MyController : Controller { //для ContentType: application/x-www-form-urlencoded [HttpPost] public IActionResult Index(MyClass myclass){ return DoSomething(myclass); }
//и для ContentType: application/json [HttpPost] public IActionResult IndexFromBody([FromBody] MyClass myclass){ return DoSomething(myclass); }
private IActionResult DoSomething(MyClass myclass){ // сделай тут что нибудь с myclass // ... // ... return Json(myclass); } }
Зачем Изменения?
Разве раньше не было попроще? Может быть, но по мнению Дэмиана Эдвардса в сообществе Standup, основная причина это безопасность, в частности - предотвращение Межсайтовой подделки запросов (CSRF)
UPDATE
Вы должны решить эту проблему routing-ом, но если вы попытаетесь отобразить две вышеуказанные действия по одному и тому же маршруту, это приведет к ошибке. Решением этого будет создание пользовательского маршрута и вызов соответствующего метода по заголовку. Я понимаю что это требует больше усилий, чем этого стоит, но они говорят что эти изменения в целях безопасности, я не стал глубоко изучать как именно это предотвращает CSRF. Вы можете погуглить или же посмотреть тут

Комментариев нет:

Отправить комментарий