You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the multisite account creation API multisite_account.json will provide a HTTP response with code "200 OK" in all cases, whether the request was successful or not. In the case of an unsuccessful request, the body will then contain an error message in JSON format.
However, in the core Discourse API the HTTP status codes are not 200 in case of an error (example). So we want to do it similarly. Proposal:
Use status code "403 Forbidden" in case the account could not be created because the username or e-mail address was already taken. That seems suitable because "403 […] may be due to the user not having the necessary permissions […] or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed)." (source)
In other cases, use "400 Bad Request" if and where applicable.
Probably the implementation could just checking what status code the Discourse API used in the background sent back, and use that for the response to the client. Just as one with the forwarded JSON error message already.
The text was updated successfully, but these errors were encountered:
Currently, the multisite account creation API
multisite_account.json
will provide a HTTP response with code "200 OK" in all cases, whether the request was successful or not. In the case of an unsuccessful request, the body will then contain an error message in JSON format.However, in the core Discourse API the HTTP status codes are not 200 in case of an error (example). So we want to do it similarly. Proposal:
Use status code "403 Forbidden" in case the account could not be created because the username or e-mail address was already taken. That seems suitable because "403 […] may be due to the user not having the necessary permissions […] or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed)." (source)
In other cases, use "400 Bad Request" if and where applicable.
Probably the implementation could just checking what status code the Discourse API used in the background sent back, and use that for the response to the client. Just as one with the forwarded JSON error message already.
The text was updated successfully, but these errors were encountered: