heartsentwined/ember-auth

Auth.Request.Jquery.signOut() does not trigger signOutSuccess on success.

Closed this issue · 2 comments

In the Auth.Request.Jquery (ember-auth.js, line 237) you set explicitly dataType in ajax settings to json. REST uses DELETE method on signOut() where server doesn't return any valid JSON, just 200 OK. This cause request fail (since jQuery 1.9). $.ajax has "Intelligent Guess" of data type by default. So if I comment line 237, everything works fine. Could you please check this?

Thanks a lot for your great job!

Ah, that hard-coded line. I was puzzled at that one too myself, but I saw ember-data core code doing that, and I thought, oh, they must have a very good reason to do so, right? So I did the same in ember-auth.

Here is what I have reasoned out: what can ember-data do if the server returns an empty response? As in, really empty, not an empty object {}. The empty object presumably represents an empty data set, so ember-data can still interpret that; but the empty response? Presumably some unintended error has happened? Anyway it goes to error, because ember-data can't understand the response.

Here is a similar logic in ember-auth: you have to declare a response adapter beforehand (json in this case), and ember-auth will expect responses to be in that format. What if it is not a valid json? #74, for example, described a case where the server returned html - perhaps a generic 404 or 500 page during development? or worse, perhaps the dev forgot to turn off showing the 500 error page in production environment? In any case, it is not valid json, ember-auth can't understand it, so presumably something bad has happened.

An even more extreme example: what if the server returns 200, but an html body? Should ember-auth trust the 200, or fail because the response body is malformed?

What about the empty response string? Should ember-auth interpret that as an allowable behavior? Or fail because it is considered as malformed response? The DELETE method doesn't have to come with an empty response. Perhaps the server performed some housekeeping work when a user signs out, and would send back data on, e.g. number of x models deleted for the user, back in a json response? Then it should definitely treat an empty string as malformed response.

One of the API at our production apps, for example, sends back the signed out user ID, because it only requires an auth_token to sign out a user. The client app can now know which user was signed out.

In summary, ember-auth now takes the "stricter" route, and require at least an empty json object ({}), to be treated as acceptable response.

Sorry it's a rather incoherent write-up. The truth is, I myself am not sure of the proper / correct treatment of empty string responses. I can see persuasive reasons of both accepting it and treating it as malformed response. More thoughts?

Good points. Agree. It is really better to be sure that you've got an appropriate server answer that to be flexible in such a case. I'll ask our backend developers to provide a valid JSON object answer on any operations. So I close the issue.

Thanks!