After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 678151 - Support Flickr
Support Flickr
Status: RESOLVED FIXED
Product: gnome-online-accounts
Classification: Core
Component: general
3.7.x
Other All
: Normal enhancement
: ---
Assigned To: GNOME Online Accounts maintainer(s)
GNOME Online Accounts maintainer(s)
Depends on:
Blocks: 697675 700897
 
 
Reported: 2012-06-15 10:03 UTC by gnome
Modified: 2013-06-10 14:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add Flickr (19.16 KB, patch)
2012-09-25 18:04 UTC, Debarshi Ray
none Details | Review
flickr: Add to docs (1.52 KB, patch)
2012-09-25 18:04 UTC, Debarshi Ray
committed Details | Review
flickr: Add icons (8.95 KB, patch)
2012-09-25 18:05 UTC, Debarshi Ray
none Details | Review
flickr: Use m.flickr.com for the OAuth endpoints (1.23 KB, patch)
2012-09-25 18:05 UTC, Debarshi Ray
committed Details | Review
flickr: Update README (651 bytes, patch)
2012-09-25 18:06 UTC, Debarshi Ray
committed Details | Review
Add Flickr (19.16 KB, patch)
2012-09-27 11:52 UTC, Debarshi Ray
committed Details | Review
flickr: Add icons (3.87 KB, patch)
2013-06-10 14:38 UTC, Debarshi Ray
committed Details | Review

Description gnome 2012-06-15 10:03:29 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
Comment 1 gnome 2012-06-15 10:15:46 UTC
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.
Comment 2 Debarshi Ray 2012-07-12 12:29:15 UTC
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.
Comment 3 gnome 2012-07-12 12:49:00 UTC
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.
Comment 4 gnome 2012-07-12 12:49:47 UTC
s/I discuss this/I could discuss this/
Comment 5 Debarshi Ray 2012-07-13 08:39:00 UTC
(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).
Comment 6 Debarshi Ray 2012-09-25 18:04:14 UTC
Created attachment 225145 [details] [review]
Add Flickr
Comment 7 Debarshi Ray 2012-09-25 18:04:50 UTC
Created attachment 225146 [details] [review]
flickr: Add to docs
Comment 8 Debarshi Ray 2012-09-25 18:05:22 UTC
Created attachment 225147 [details] [review]
flickr: Add icons
Comment 9 Debarshi Ray 2012-09-25 18:05:56 UTC
Created attachment 225149 [details] [review]
flickr: Use m.flickr.com for the OAuth endpoints
Comment 10 Debarshi Ray 2012-09-25 18:06:29 UTC
Created attachment 225151 [details] [review]
flickr: Update README
Comment 11 Debarshi Ray 2012-09-25 18:12:15 UTC
I cleaned up Willem's patches and implemented the changes asked for in comment #2.
Comment 12 Debarshi Ray 2012-09-25 18:19:23 UTC
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
Comment 13 Debarshi Ray 2012-09-27 11:52:44 UTC
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
Comment 14 Debarshi Ray 2012-09-27 12:02:21 UTC
Willem, I am curious about where you got the icons. They are not the ones at http://www.flickr.com/about/goodies/
Comment 15 Debarshi Ray 2012-09-27 12:55:15 UTC
Yahoo! has some brand guidelines: http://pressroom.yahoo.net/pr/ycorp/guidelines.aspx
Comment 16 Debarshi Ray 2013-06-10 14:38:36 UTC
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.