Closed heymarkreeves closed 9 years ago
(This one's top priority so we can get feedback to Jamie)
Looking into it further, the validation script's "remote" method does parse the return value as JSON, but it still requires it to be a single value "true" or "false" or "[your custom error message here]" rather than a fully formed JSON structure. It's apparently checking for an "exactly equals" true. Somewhat misleading documentation, for sure. So it sounds like we'll need to create a custom validation method?
@jamiefolsom Unless you're comfortable supporting a response that's just a simple "true" string, rather than a full JSON payload, I think we'll need to code a function to parse the status codes you've been using, and let the validator run that function. Do you agree? This would apply to both login (/tokens) and the existing email check endpoint.
Hi, Sherri!
If we enable a custom function, what should its return
be for the jQuery Validator? Boolean true?
I'm assuming that this should be:
/registrations
using _method: HEAD
return true
based on the correct status code from the APIDoes that sound valid?
Thanks!
Mark
Hey there, Mark! That sounds like it could work...
Hi folks, so it sounds like we're going to need that existence check for the /registrations
endpoint, but I will wait for confirmation from you. Thanks!
Also, let me know what you see that will be needed for /tokens
... That token is on the user model, and is persisted in the db, so logging in basically checks that the given email and password match, and if so, returns that existing user's existing token. This is why we're going to (eventually) serve this API over SSL, which incidentally bears mentioning, in case we hadn't been explicit about that. Thanks!
It looks like we should code this using addMethod
so that we have a function we can apply to the email field. That function should dynamically take the value of the field (email), call the remote method (using _method: HEAD
) and parse the status codes that come back before returning true
or false
to the validator.
Hi, @jamiefolsom! We'll follow up on /tokens
, but for this one, I'd like to try to make the HEAD
approach work in your #48. Has that been implemented?
Thanks!
Copying this over here from #48 for documentation:
use a HEAD route, with a search parameter on the existing
/registrations
endpoint, so:HEAD /registrations?email=jfolsom@mit.edu
would return200 OK
if the user exists, and404 OK
if not, each of which you could then handle appropriately in the front end. If that sounds good to you, I can get started setting it up. See: http://www.pragmaticapi.com/2013/02/14/restful-patterns-for-the-head-verb/ and scroll down to "Existence checks"
Hi @circa1977 -- that has not been implemented yet -- either I or Liam will get that done as soon as possible. Thanks.
In the HyperStudio issues, https://github.com/hyperstudio/artx/issues/47, https://github.com/hyperstudio/artx/issues/48, we've gone back and forth a bit on using status codes vs. response payloads. Jamie has offered to return JSON-encoded responses, but we aren't sure that the validator we're using can parse those, or if it needs just a simple
true
string in the body of the response.Can we vet what the validator can work so we can give Jamie direction? If it turns out that we need to code a custom validation function to parse a JSON response, I'd rather put that effort into a custom function that parses the status codes being returned.
This does not address that the status codes for login errors should be optimized, but Jamie's solution for status codes for "check email" is valid.
If the validator can parse JSON, we can ask Jamie to consistently return JSON. If it can't by default, we'll take on coding a custom function that checks status codes.
Thanks!