REST error reporting

[kam-rezvani]

Hi,
Looking through trace variables, I am unable to see errors returned by a service call. I am using the login service:
/<version name>/users/login
Errors:
When the server-side reports an error, it returns a JSON object in the following format:
{
“message”:error-message,
“code”:error-code
}
The following errors may occur during the Login API call.

Error Code
Description
2002
Version is disabled or provided wrong application info (application id or secret key)
3000
Login has been disabled for the user account.
3001
Missing login settings, possibly invalid application id or version.
3002
User cannot login because Multiple Logins disabled and there is a logged in user for the account.
3003
Invalid login or password.
3006
Either login or password is an empty string value.
3034
User logins are disabled for the version of the application.
3036
Account locked out due to too many failed logins.
3038
One of the required parameters (application id, version, login or password) is null
3044
Multiple login limit for the same user account has been reached.
8000
Property value exceeds the length limit

The error code I receive is an http 400 or 401 and not the codes listed above. I am using the REST API.
Thanks

[mark-piller]

Hi,

What does your REST request look like? And by that I mean the following:

HTTP verb: do you use GET, PUT, POST, DELETE? URL Request headers Request body

Thanks, Mark

[kam-rezvani]

Hi,

Thanks for the reply. Per your request the following are the answers to your questions:

1. verb: POST
2. url: ‘https://api.backendless.com/v1/users/login’
3. headers are set by the following statements:

httpClient.setRequestHeader(‘application-id’, backendlessAppID);

httpClient.setRequestHeader(‘secret-key’, backendlessSecretKey);

httpClient.setRequestHeader(‘Content-Type’, ‘application/json’);

httpClient.setRequestHeader(‘application-type’, ‘REST’);

4.Body: {“login”:“222222222”,“password”:“12341234”}"

Thanks,
Kam

[mark-piller]

It looks good. There must be a problem with how the request is created. Do you use a framework for that? What is “httpClient”?

Get some sort of proxy utility that will show you what the final request looks like. If you get 400 or 404 back, it means either the URL was not sent correctly, a header is missing or wrong verb was sent.

[kam-rezvani]

Hi,

Again, thanks for the quick response. I see that I misspoke earlier. Generally, this payload is successfully executed without a problem. Now, if there is a problem, for example, the login is incorrect or the user failed to validate email and tried to login, then the proper error codes are not returned. I only get the http error code and not the internal Backendless codes that are more descriptive of what actually took place on the server side. Hope this is clear.

[kam-rezvani]

Hi,

Again, thanks for the quick response. I see that I misspoke earlier. Generally, this payload is successfully executed without a problem. Now, if there is a problem, for example, the login is incorrect or the user failed to validate email and tried to login, then the proper error codes are not returned. I only get the http error code and not the internal Backendless codes that are more descriptive of what actually took place on the server side. Hope this is clear.

[mark-piller]

We would need to be able to reproduce the problem. Please describe your environment as detailed as possible.

Thanks!

[kam-rezvani]

Calls are being made from an iOS app that is complied with Appcelerator Titanium framework.

Thank you for your help. Let me know if you need more details.

[mark-piller]

I just ran the same call using curl and here’s what I got. As you can see the response with the error code (3003 in this case) is there:

http://support.backendless.com/public/attachments/8f21e21cc41b4e1e143df6d205df8ee1.jpg&lt;/img&gt;

There is got to be a way in Titanium to get the body of the response when the HTTP response is 401

[kam-rezvani]

Hi Mark,

Thanks for your detailed explanation. It was helpful in my debugging effort.

Here is what I found. At the IDE level, when a backend request is successful, the trace variables look like this:

http://support.backendless.com/public/attachments/1ce85a990bcc948cb839b6e7f033be73.png&lt;/img&gt;

So by parsing e.text, I am able to use the data app needs.

On the other hand, when the request fails, the trace variables look like this:

http://support.backendless.com/public/attachments/a6ed1672a2ce20b649a3e2caa96009e8.png&lt;/img&gt;

As you can see, the only useful information is e.code which is the http error code. There is no sign of the Backendless error code and message in the payload returned.

I also tested the CURL interface to isolate the problem further. The CURL request works in that in does return the Backendless error. So I can’t be certain where the ball is getting dropped as far as returning the correct error payload to the Eclispse IDE.

In examining the CURL response I noticed ANOTHER problem that I want to bring to your attention. I noticed that the server returns what appears to be an incorrect error message to an invalid login:

http://support.backendless.com/public/attachments/8208e124a744861a408dd13909a00dbf.png&lt;/img&gt;

Thanks,
Kam

[mark-piller]

Hi Kam,

It looks like when the response results in HTTP 401 (which makes perfect sense when login is not successful for the reasons described here), Titanium hides the body of the response from you. You know the body is there, because you saw that server returns it when you make a request with curl. So the essence of the problem is figuring out how to get the response body using Titanium.

As for the malformed JSON request, please send the exact curl command you use to support@backendless.com with a link to this topic so we can run it on our side.

Regards,
Mark

[kam-rezvani]

Hi Mark,

So what I am hearing from you is that this is a Titanium issue which makes sense the way you described it.

My question is that since Titanium is Javascript-based, would you recommend that I use the Backendless Javascript API in the future rather than the current REST API I am using with this glitch?

Do you have any opinion on this one way or other?

I did submit the malformed JSON request issue to support btw.

Thanks,

Kam

[mark-piller]

Hi Kam,

If you use the JS API, things should be much easier. The library should work just find in the TI environment. In fact, we’re working on a Titanium-based project right now converting it from Parse to Backendless and in there we used our JS library. There were no issues with it at all.

Regards,
Mark