13 replies to this topic

[baumgarr]

I have a couple of questions regarding the OAuth API when compared with the old userid/password authentication method for desktop apps.

The first question is regarding the callback URL. From what I've read, I would think that if I registered a custom URL, I would get it back. for example, if I specified a callback of "myapp", I should get a URL starting with myapp when the user presses "Authorize". What I'm seeing is an HTTP link starting with sandbox.evernote.com/Home.action?myapp? I tried changing myapp to myapp:// (encoded) but I get a similar response. It doesn't really matter as long as I know what to look for, but I wanted to be sure I wasn't a difference between the sandbox & production servers.

Next question: The authorization token that I receive back. Does it completely replace the authorization token I was receiving from userStore.authenticate? If so, does that mean I no longer need to refresh the token every hour?

Final Question: I still need to authenticate to linked notebooks the same (except using the new auth token from OAuth), correct?

Thanks for the answers.

[SethH]

1) Yes, although how you set up callback URLs is platform-specific. You can pass us whatever callback URL you want (e.g. myapp://callback) but you need to tell the local system to send such URLs to your application. We'll have to see how to best do this for NixNote, I'm not sure there's a magic bullet; we may end up implementing out-of-band OAuth validation on our side. This is pretty common, but we don't support it yet. Here's LinkedIn's description:

If the oauth_callback is set to 'oob', the user will get an "out-of-band" experience (generally used for applications running outside of a web browser), where they will get the oauth_verifier as a PIN which they need to input into your application to complete the authorization process.

2) Yes, this is a replacement auth token that can be used in exactly the same way, but will be valid for 1 year. No need to refresh.

3) Yes, although at the moment authenticateToSharedNotebook doesn't work with OAuth API keys. We'll be resolving this shortly.

[baumgarr]

The thing that is confusing me is I didn't get the URL myapp:// in return, but an HTTP reply to the sandbox with myapp in the URL. Anyway, it doesn't matter as long as I know what to expect.

I got the callback and everything works (at least in the sandbox). I'm able to synchronize and the things I've tested seem to work fine (I didn't test shared notebooks). I like that I no longer need to do the refresh every hour and people can revoke access easily, but this is certainly a lot more complicated than a simple userid & password. I've submitted a request for production permissions, so hopefully it works there too.

For anyone else using Qt, I had to use a custom QNetworkAccessManager and override the createRequest method to examine every request coming in through the QWebView the user was authenticating through. Once I see one with the URL with the proper response I strip out the OAuth string. It's ugly but it works and it only has to be done once a year. I tried setting a desktop URL handler to look for myapp:// but that didn't work since I wasn't getting that URL in return.

Can you please let us know when the authenticateToSharedNotebook works for OAuth keys? I'd like to give this to a few people to beta test, but I know that some of them use shared notebooks and this will be a major problem.

Thanks again Seth!

[SethH]

Ah yes, if you're doing the authorization in an embedded browser window, then you can trap the callback.

I'm interested in why the desktop browser didn't work. What was the full URL that you were redirected to after approving access?

[AndyDent]

Ah yes, if you're doing the authorization in an embedded browser window, then you can trap the callback.

Could the same approach be used on iOS for a much nicer workflow? I find the transition out to Safari for authorisation somewhat disturbing and am not looking forward to customer feedback.

[baumgarr]

I used an embedded browser because I thought all of the interaction between the two could be problematic given the number of different window managers and browsers on Linux. I wanted to avoid the "it doesn't work on window manager x when I run browser y". I fight that enough of the time.

If I set the callback to myapp, the response I see back is an http URL starting with "sandbox.evernote.com/Home.action?myapp?". If I set the callback to myapp:// then the :// is also part of the URL I'm receiving back. I received permission to work on this in production and it seems to be similar there. Like I said, it is on big deal as long as it is consistent. If I'm the only one experiencing it then it is probably something odd in Qt or (more likely) the developer's ignorance.

Please give us a heads up when OAuth works for shared notebooks and I'll turn it out to people to test. My testing in production so far hasn't found any problems but I'll need to have more testing before issuing it in a new release.

[dwhogg]

Does Evernote support OAuth 2 as well as OAuth 1?

[Julien Boedec]

Currently, Evernote only supports OAuth 1.

[Paulovic]

Is there any way to use username and password authentication instead of OAuth in Android, in the same way Evernote Hello apparently does? I'd like to control all the user interaction within my app, I don't see the browser authentication as the most elegant way to do so.

Thanks.

[AndyDent]

Is there any way to use username and password authentication instead of OAuth in Android, in the same way Evernote Hello apparently does?

No, even if you have an old key which supports this, they are no longer promoting them from the sandbox. If you already have one that has been activated on production, it will be barred from 1st Nov, as per the recent email.

I don't like the user experience either but we're stuck with it.

One technique that may help, In response to a Linux user's comments, Seth confirmed yes, if you're doing the authorization in an embedded browser window, then you can trap the callback. I haven't had time to try this on iOS yet but it sounds promising.

[Richard Haven]

So UserStore.authorization() is deprecated ?

Is there any way to use username and password authentication instead of OAuth in Android, in the same way Evernote Hello apparently does?

No, even if you have an old key which supports this, they are no longer promoting them from the sandbox. If you already have one that has been activated on production, it will be barred from 1st Nov, as per the recent email.

[Richard Haven]

Yes, yes it is.

[baumgarr]

I'm not sure there's a magic bullet; we may end up implementing out-of-band OAuth validation on our side.

I was curious if there is any plans to support an out-of-band OAuth validation? The method I'm using works for most people, but there are those that have problems (firewall, unable to get OpenSSL to work, etc). An out-of-band method would help.

[Philippe Saint-Pierre]

I'm not sure there's a magic bullet; we may end up implementing out-of-band OAuth validation on our side.

I was curious if there is any plans to support an out-of-band OAuth validation? The method I'm using works for most people, but there are those that have problems (firewall, unable to get OpenSSL to work, etc). An out-of-band method would help.

Hi, in my case, an out-of-band validation would be more than welcome (out of browser client), have there been any changes regarding this? Thanks!