不提供或不匹配时的适当http状态代码，用于额外的身份验证步骤

Question

问题

应用程序希望客户端在大多数路由上发送带有访问令牌的标头Authorization。现在有了一个新功能，并且一些新的路由不仅期望Authorization头，而且期望一个pin属性，该属性在请求的正文中具有6个长度的字符串。如果pin的值与数据库中存储的用户pin的值不匹配，则应拒绝该请求。

由于用户已通过身份验证（在Authorization标头中发送了有效的访问令牌），但应使用错误的pin来拒绝请求价值吗？

上下文

该应用程序现在将支持付款，并且在请求正文中需要pin属性的路由是进行付款的路由，因此它们会在应用程序内花费用户的积分。这就是为什么它只需要在几条路由上发送pin的原因。

我认为的解决方案

1. 使用422 Unprocessable Entity，因为由于体内pin值错误而无法处理请求。
   • 问题：：当其他一些验证失败时，也会发送状态代码422，因此似乎不正确，因为pin与授权有关。 / li>
2. 使用401 Not Authorized，因为错误的pin值表示用户未能提供所有正确的凭据。
   • 问题：实际上，用户实际提供了有关应用程序在每个路由上期望的凭据，直到现在。新功能之后，需要在应用程序中被认证的凭据将不匹配。 401现在将意味着两种错误，而不仅仅是用户未通过身份验证。
3. 使用403 Forbidden。
   • 问题：：尽管不允许用户 ，但这与角色权限无关。

额外的问题：pin在标头而不是正文中发送会更好吗？

Answer 1

我认为422、403和400都“足够好”。我可能会选择400，因为这是一种特殊情况，恕我直言，状态代码都不完美。