HTTP status for “email not verified”

后端 未结 2 828
慢半拍i
慢半拍i 2021-02-19 02:49

I have seen the list of all HTTP status codes. However to me it looks like there is no code for \"email not verified\" (used for authentication/authorization). Did you ever had

2条回答
  •  萌比男神i
    2021-02-19 03:17

    While CodeCaster has provided a very definitive answer as a comment, that which is correct is sometimes not appropriate.

    Firstly, you'll see there is no mention of email addresses in the specs. Similarly there is no mention of shoe sizes, model railway gauges, breeds of dogs nor many other things. It is not relevant to HTTP. This is just a data item.

    You seem to have some state associated with this data item which you use for authentication purposes - but don't provide any explanation of that state nor how it is applied. I assume that you mean that the "not verified" state means that the only association between the data item and the user interacting with your site is an assertion of the user. And further that you do not allow the user to authenticate with this as a token.

    It may seem I'm being pedantic here - but there are other, valid interpretations of "email not verified". You should have provided more information in your question.

    There's another gap in your story: which request are we taking about here? Again, I'll take the liberty of assuming that the request is an attempt to authenticate.

    In this case, there is nothing intrinsically wrong with the request. There is nothing intrinsically wrong with the client. There is nothing intrinsically wrong at the server. Not permitting the user to authenticate is a policy decision based on the data.

    Another critical bit of information missing from your question is what is actually making the request. If its a form sent by a browser, then returning anything other than a 200 OK (or 204, or a redirect to a 200) to MSIE will, by default, cause the browser to display an internal message and not the content you send.

    OTOH if the client is an application running on the users device, or an Ajax request, then you control the API and can define your own semantics. If you want to return a 692 status code to represent this condition, then you can return a 692 error code. You can even inject your own headers in the response (by convention these should begin with 'X-').

    In the defined state the authentication fails. But returning a 401 response will prompt a browser to attempt HTTP authentication - which doesn't address the issue.

    IMHO, the nearest existing code is 403 or 422. But based on the information you've supplied I can't say if thats what you should be using.

提交回复
热议问题