GNOME Bugzilla – Bug 678151
Support Flickr
Last modified: 2013-06-10 14:39:15 UTC
Hi, I've added support for Flickr to gnome-online-accounts, please see my Github repository at https://github.com/wvengen/gnome-online-accounts git://github.com/wvengen/gnome-online-accounts.git It would be nice if this could be merged! This is my first contribution to gnome-online-accounts, so please let me know if some (style) changes would be desired. Regards, - Willem
For the moment I've only enabled the 'read' scope; when this has been reviewed, it may be a good idea to set this on 'write' or 'delete', so that full access is given. Ideally this would be user-controlled, but it cannot be set _after_ user confirmation, so I don't see how.
At first glance ... I am not convinced why you need to use an external browser. You should define the following pure virtual methods: + get_authentication_cookie: it is used to detect when the user has logged in, so that we can remove the "Cancel" button from the embedded browser. + parse_request_token_error: it is used to parse any error that might occur during the request token phase into a human understandable error message. See the Google provider for examples.
Thanks for looking into this! A major reason for using OAuth instead of username/password is that a client application does not know the username/password but still is granted (partial) access to a protected service. By embedding the browser in an application, the application does have access to the username/password. By teaching the user to use a trusted system component like the web browser, the threat of leaking passwords through malicious software is diminished. The use of an embedded browser is explicitely discouraged in draft-ietf-oauth-v2-threatmodel, see http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-06#page-19 . See also http://www.ietf.org/mail-archive/web/oauth/current/msg08830.html . There are other drawbacks as well, although they might not be so much of a problem right now: http://wiki.oauth.net/w/page/27249271/OAuth%202%20for%20Native%20Apps . Still, as gnome-online-accounts is a system component, it may make sense to use an embedded browser. I discuss this up on the -oauth mailing list to see if this would be a sensible exception to the rule.
s/I discuss this/I could discuss this/
(In reply to comment #3) > A major reason for using OAuth instead of username/password is that a client > application does not know the username/password but still is granted (partial) > access to a protected service. By embedding the browser in an application, the > application does have access to the username/password. By teaching the user to > use a trusted system component like the web browser, the threat of leaking > passwords through malicious software is diminished. There is no guarantee that the web browser is trusted either if the user had just installed it from some random location. Distributors usually GPG sign their packages, and tools like yum are supposed to check if those signatures match or not. As long as they match, it means that the user is using what the distributor intended to distribute. Since this is all free software you can always audit the sources (both the distributor's and GNOME's) and check what is going on. Moreover the embedded browser uses the same stack as the system browser (Epiphany).
Created attachment 225145 [details] [review] Add Flickr
Created attachment 225146 [details] [review] flickr: Add to docs
Created attachment 225147 [details] [review] flickr: Add icons
Created attachment 225149 [details] [review] flickr: Use m.flickr.com for the OAuth endpoints
Created attachment 225151 [details] [review] flickr: Update README
I cleaned up Willem's patches and implemented the changes asked for in comment #2.
I am a little concerned that Flickr's documented endpoints do not work with HTTPS. Ubuntu is using a different endpoint in their SSO: http://bazaar.launchpad.net/~online-accounts/online-accounts-account-plugins/trunk/view/head:/src/flickr.vala
Created attachment 225252 [details] [review] Add Flickr There are 2 things that need further investigation. The perms (or scopes) parameter is specified in the Flickr project page because we do not have a way to specify it in our OAuth 1.0 implementation. We have the get_request_uri_params method but it is used when fetching a request token, while Flickr wants it while getting the authorization token [1]. Denying access via the OAuth web page takes you to http://www.gnome.org/ This is because the "NO, THANKS" widget in the web page is an anchor element whose href property is set to the URL specified as GNOME's website in Flickr's App Garden. We can not intercept the click on this element because the "click" event handler is not being called (WebKit bug?). [1] http://www.flickr.com/services/api/auth.oauth.html#authorization
Willem, I am curious about where you got the icons. They are not the ones at http://www.flickr.com/about/goodies/
Yahoo! has some brand guidelines: http://pressroom.yahoo.net/pr/ycorp/guidelines.aspx
Created attachment 246404 [details] [review] flickr: Add icons We got permission from Yahoo to use the Flickr icons. So lets add the ones from http://www.flickr.com/about/goodies/ Unfortunately these don't look as good as the other icons that we have -- Google & Facebook.