On Wed, Aug 21, 2013 at 5:05 AM, Nicolas Vervelle <nvervelle(a)gmail.com>wrote;wrote:
I'm completely new to OAuth, so bear with me if my
questions are basic or
I missed a point ;-)
You have some good questions here.
I'm interested in developing this for WPCleaner
[1], which is a desktop
application.
Is the callback URL required ? If so, which one should you use for a
desktop application ?
A callback URL is required.
In general with OAuth, a desktop or mobile app has to direct the user to a
web browser in some manner to go to the site, log in, and authorize the
application.
If you embed a web browser control right in your application, you can
probably watch for it to be directed to your specific callback URL, remove
the web browser control, and proceed to process the response. On the other
hand, and end user shouldn't necessary trust a web browser control to not
be sniffing their password as they log into the site to authorize (but on
the gripping hand, the desktop app might sniff the keystrokes even with an
external browser, so...))
If you open an external browser, chances are you can't catch the callback
URL, so your options are limited to basically having a web page somewhere
that just displays the necessary verification token for the user to copy
back into your application. Perhaps we should allow for the callback URL to
be left empty, in which case the OAuth extension would do just this.
For that matter, it's possible the app is unable to open a browser at all.
In that case, the app could always just display the URL (possibly using a
shortener), instruct the user to visit that from a full-featured computer,
and then enter the verification code as mentioned in the above paragraph.
Has anyone implemented the connection to WMF wikis using OAuth under Java ?
I don't think the MediaWiki OAuth extension does anything particularly
unusual, so you should be able to start with any other Java implementation
of an OAuth 1.0a client.
For this to work, you request client tokens (including secret key) for the
> client : do this tokens need to be kept privately ?
> I'm wondering, because keeping secrets for an open source desktop
> application is not easy.
That is a good point. I hope someone will correct me if I'm wrong, but I
can't think of any way to prevent a determined attacker from extracting the
keys from a desktop or mobile app (open or closed source) and impersonating
it. Which means that there's no way for MediaWiki to know that the app is
really who it says it is, meaning that the OAuth CID tags for such apps
aren't any more reliable than the existing method of including something
like "([[WP:TW|TW]])" in the edit summary. On the other hand, this in
itself shouldn't compromise end-user security, because the malicious app
would still have to steal the access token from the legitimate app's
storage on the end user's computer.
As far as I can tell from looking around, no one really has a solution for
this. There are reports that Twitter blocks the consumer key if it finds it
has been compromised, which is widely criticized. On the opposite end, it
seems Google just lets such apps use "anonymous" for the consumer secret,
and presumably doesn't try to positively identify the consumer at all.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
