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

#c_sharp #aspnet_core #aspnet_core_mvc

Когда-то в 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? И почему поведение изменилось?
    

Ответы

Ответ 1

Этот вопрос можно решить таким путем: нужно создать две разные 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.
Вы можете погуглить или же посмотреть тут.