Bad error handling if user de-authorized app about dropbox HOT 3 CLOSED

The problem is that invalid access tokens are definitely unexpected behavior. Theoretically a Dropbox access token should be good for a "long" period of time. Realistically, they go bad because of things like server hiccups or Memcached issues or whatever. When this happens, I think raising an exception is the appropriate thing to do, as it is an error state.

Authorization only happens once during the OAuth process. Once Dropbox::Session has the access token it does no more authorization. To check for a valid auth token would require the overhead of an additional API call, which is not something I'd like to do "automatically." My recommendation, if you want to write robust code that can handle invalid auth tokens, is to make a quick call to API#list (or some equally harmless method) when your app starts (or otherwise periodically) and just check for a 401.

I'm still ears though if you feel strongly about this and would like to make a further case.

from dropbox.

I see your point. However it's still a very common use case. By treating the state as unauthorized instead of an error, you can prevent every application from having to handle this case individually. Which is quite a gain, in my opinion.

Possible compromises would be a dedicated method to check for this case, or an option to disable the check (and thus the overhead).

For now, I'm using this:

# user de-authorized account - request re-authorization
begin
  @dropbox.account
rescue Dropbox::UnsuccessfulResponseError
  redirect_to oauth_authorize_path
  return false
end

from dropbox.

Closing old tickets.

from dropbox.