JSON Response with status code for Admins Verifying Accounts, especially for already verified users#306
JSON Response with status code for Admins Verifying Accounts, especially for already verified users#306ochan1 wants to merge 2 commits intosnap-cloud:masterfrom
Conversation
controllers/user.lua
Outdated
| -- admins can verify people without the need of a token | ||
| if self.params.token == '0' then assert_admin(self) | ||
| if self.queried_user.verified then | ||
| return okResponseWithStatusCode('User ' .. self.queried_user.username .. |
There was a problem hiding this comment.
Hmm, what's the reason for the new method, and the 'Already Verified' argument? The status_code argument of the jsonResponse method is meant to be a HTTP Status code, in this case it should always be 200.
There was a problem hiding this comment.
It was meant to be a message representing if the user was verified successfully or already verified, so the bulk verify can let the verifying person know who got verified or who was already verified
There isn't really a way of distinguishing between either one unless one were to use the message string, which is prone to be modified in the future since it is a message
I changed the name to make it less confusing between a Request status code and the Status of reaching this point of the code (I called it the State Message)
2 participants
This adds backend logic to allow for processing one-by-one accounts approved for verification
The original code returns an HTML for when the user is already successfully verified, but it can cause the Cloud Request code to error when the verify_user is called using the Cloud.prototype.request in Snap!'s cloud.js since it assumes a JSON request
This modification returns an OK JSON when an admin with a token of 0 approves a user
An additional field showing the status code of the verification is used to allow for messages to be shown why a user has failed verification upon detection of a certain status code (Verified, Already Verified, or Failed Verification)
This does not preprocess users one by one but does show which users fall under each of the three categories
This was made in conjunction with snap-cloud/SnapSite#111, but this Pull Request is not dependent on that one (but the SnapSite Pull Request is dependent on this snapCloud Pull Request)