You can clone with
HTTPS or Subversion.
When I call delta() on an unauthenticated client, I get the following error:
SyntaxError: Unexpected token u
at Object.parse (native)
at Object.exports.app.client.delta (/home/dan/node/node_modules/dbox/dbox.js:69:24)
This was the result of my code failing to wait on an asynchronous function to complete, leading it to think a client was authenticated when it was in fact not. Still, shouldn't this be caught (or blocked) by dbox so as to be described a little better in the error?
So in the setup guide it stands how you can setup the authorization. But actually i think its a good idea to block every function call until the auth is setup. What do you think about that @sintaxi ?
I think the key is to pass back a useful error. Sometimes the client the does the oauth handshake is not the client that does the speaking to dropbox. Perhaps we can have validation on the client() call to ensure that the properties are at least present.
This is related enough that I won't open a new issue.
I think Dropbox decided to throttle back my API requests (API call in infinite loop, whoops). When I call any method of an authenticated client, I get back this error:
SyntaxError: Unexpected token <
at Object.parse (native)
at Request.exports.app.client.account [as _callback]
Obviously, I'm getting back some sort of HTML page from Dropbox, most likely an API error. But because the SyntaxError is thrown before the callback is called, I can't (easily) check the status code to see what the error is. Should the response from Dropbox even be passed to the parser at all for non-200 status codes (which I assume this is)?
Currently we are relying on Request and its implementation of error.
But maybe we should code the errors from the dropbox API into this lib. In your example with the account/info could you please try to type out the r.statusCode ?
I've seen this one a decent number of times but haven't put together the patch for it yet. The problem (from what I can tell) is from the amazon(?) loadbalancer redirecting to a non-dropbox site. We really need to put the JSON.parse in a try/catch to make sure we are not attempting to parse HTML as JSON. This should never be an issue if we are getting a response from Dropbox since they always return valid JSON, but for some reason, occasionally I get responses from Non-Dropbox sites.
I submitted a pull request to resolve the "Unexpected token <" issue. See issue 57