search

INCF / biostar-central

DEPRECATED, please go to upstream on
http://github.com/ialbert/biostar-central
Other
4 stars 4 forks source link

ORCID login integration #39

Closed brainstorm closed 10 years ago

brainstorm commented 10 years ago

http://support.orcid.org/knowledgebase/topics/19247-rest-api

brainstorm commented 10 years ago

There are some good ideas on what to do with ORCID on this GSoC comment:

https://github.com/INCF/biostar-central/issues/15#issuecomment-43402081

@unidesigner, @nimiq will be working on ORCID pretty soon, if you have more specific wishes, code snippets, or mockups, now it's the time to elaborate about it in this issue.

brainstorm commented 10 years ago

Being worked on: https://github.com/pennersr/django-allauth/pull/672

brainstorm commented 10 years ago

@nimiq Good job upstream! Now it should be tested in the context of *-stars. I would suggest that the first modification goes to the user profile view, adding up ORCID (if you aren't working on it already) ;)

puntonim commented 10 years ago

I am working on it already. The ORCID login is just straightforward, I tested that. I've also prepared a special query to fetch the user profile from ORCID. Now it's just a matter of deciding what info to keep and how to display it in Biostars. I am preparing a couple of questions for you and Istvan.

puntonim commented 10 years ago

I contributed to django-allauth adding the support for ORCID (I've just finished off the last thing). At the end of the first ORCID login process for a user, the user bio is read from orcid.org and automaticaly stored in the relative SocialAccount instance in JSON format like this example. That example corresponds to the following profile: orcid

My questions are:

brainstorm commented 10 years ago

I would just leave it as it's stored now (SocialAccount, JSON) and show an ORCID field with an URL in the BioStar user profile page when and if the user logs in via ORCID (sth such as "ORCID: http://orcid.org/0000-0002-2961-9670").

@ialbert, @satra, would you like to see more info listed in the user profile or used differently?

ialbert commented 10 years ago

Yes we do need to think about the way to display that information. We could for example fill in the user "About me" profile with content generated from this JSON.

For now can you add (or document) a method or function call that would retrieve this JSON content for any given user.

great job in all,

best,

Istvan

On Tue, Jul 29, 2014 at 5:10 AM, Roman Valls Guimerà < notifications@github.com> wrote:

I would just leave it as it's stored now (SocialAccount, JSON) and show an ORCID field with an URL in the BioStar user profile page when and if the user logs in via ORCID (sth such as "ORCID: http://orcid.org/0000-0002-2961-9670").

@ialbert https://github.com/ialbert, @satra https://github.com/satra, would you like to see more info listed in the user profile or used differently?

— Reply to this email directly or view it on GitHub https://github.com/INCF/biostar-central/issues/39#issuecomment-50452439.

satra commented 10 years ago

@ialbert - i do think we need to think through what aspects of the profile gets merged and integrated.

one option at this point, might be to make the orcid content show up in a specific box for now instead of merging. i don't think we will be able to alter that directly - without paying orcid. @nimiq - could we check?

ialbert commented 10 years ago

Good point we need to check what the reuse policies are - there could be unexpected limitations and downsides that need to be considered.

On Tue, Jul 29, 2014 at 9:28 AM, Satrajit Ghosh notifications@github.com wrote:

i don't think we will be able to alter that directly - without paying orcid. @nimiq https://github.com/nimiq - could we check?

puntonim commented 10 years ago

ORCID offers 2 kinds of APIs: Member API and Public API. The second one is a free read-only API with limited functionality, usable for the OAuth login process and to read users bio; Member API instead requires an organization account and a subscription with ORCID (so it is not free) and offers more functionalities (it can also write to ORCID on behalf of users).

What I implemented in django-allauth is the OAuth login process plus the profile (bio) fetching with Public API. In Biostars I used django-allauth to implement the social login like we already have with Google, Facebook and others.

I investigated a bit about reuse policies. Didn't find anything precisely related to reuse policies but still I understood the following. I, as a ORCID member, can specify the privacy setting for each piece of info in my account and there are 3 privacy settings:

Public API can only read piece of info with EVERYONE setting, thus we of course have the right to read those data.

Can we also reuse these data, by meaning f.i. displaying them in Biostar? This page states: "The public will have free access to the [Public] data for viewing and use... Our Terms and Conditions of Use (for individuals) and our Membership Agreement (for Members) state that individual data Records may not be used in any manner that is defamatory or misleading; cannot be modified so as to make them false, incomplete, or misleading; are subject to your rights of publicity; and if any person or entity uses the data for marketing purposes, they must give you the right to opt-out of such communications. Although we post this notice, ORCID does not undertake the responsibility to police third party uses of data. If you object to a third-party use of your data, you should contact and make a complaint directly to the third party". So it seems that we can reuse those data and they suggest us to respect some very reasonable community norms.

To wrap it up: by using the free Public ORCID API, we have read access to ORCID and we can build a OAuth login process and fetch profile data. We can also use and display those data in our website.

ialbert commented 10 years ago

now that I looked into this more,

I am somewhat uncomfortable by the business model of this organization that seems to want to make a living by charging other organizations that a scientists wishes to be a member of ...

On Tue, Jul 29, 2014 at 10:36 AM, nimiq notifications@github.com wrote:

ORCID offers 2 kinds of APIs: Member API and Public API. The second one is a free read-only API with limited functionality, usable for the OAuth login process and to read users bio; Member API instead requires an organization account and a subscription with ORCID (so it is not free) and offers more functionalities (it can also write to ORCID on behalf of users).

What I implemented in django-allauth is the OAuth login process plus the profile (bio) fetching with Public API. In Biostars I used django-allauth to implement the social login like we already have with Google, Facebook and others.

I investigated a bit about reuse policies. Didn't find anything precisely related to reuse policies but still I understood the following. I, as a ORCID member, can specify the privacy setting for each piece of info in my account and there are 3 privacy settings:

Public API can only read piece of info with EVERYONE setting, thus we of course have the right to read those data.

Can we also reuse these data, by meaning f.i. displaying them in Biostar? This page http://orcid.org/privacy-policy#Privacy_settings states: "The public will have free access to the [Public] data for viewing and use... Our Terms and Conditions of Use (for individuals) and our Membership Agreement (for Members) state that individual data Records may not be used in any manner that is defamatory or misleading; cannot be modified so as to make them false, incomplete, or misleading; are subject to your rights of publicity; and if any person or entity uses the data for marketing purposes, they must give you the right to opt-out of such communications. Although we post this notice, ORCID does not undertake the responsibility to police third party uses of data. If you object to a third-party use of your data, you should contact and make a complaint directly to the third party". So it seems that we can reuse those data and they suggest us to respect some very reasonable community norms http://orcid.org/content/orcid-public-data-file-use-policy.

To wrap it up: by using the free Public ORCID API, we have read access to ORCID and we can build a OAuth login process and fetch profile data. We can also use and display those data in our website.

— Reply to this email directly or view it on GitHub https://github.com/INCF/biostar-central/issues/39#issuecomment-50483796.

brainstorm commented 10 years ago

Yes, @ialbert, I didn't know they charged so much for that, it was a major setback when I learned about their model.

@nimiq, I would say that adding the ORCID url in the user profile if they authenticate through it should be more than enough for our purposes, IMHO.

satra commented 10 years ago

despite the problems, let's keep the public api here. i think they will probably change the model at some point, since many other id providers are coming into play. it's just that right now there is a lot of integration with publication services.

the other auth bit to add is webid - which is slowly getting some traction. i found this django package, but i'm asking some folks if there is something more recent.

https://github.com/bennomadic/django-webid-auth

brainstorm commented 10 years ago

Closing this issue, being followed up on PR https://github.com/ialbert/biostar-central/pull/253.

@satra, feel free to open an issue on WebID if you think it's interesting to have. The idea is good (in browser X509 has been there for a long while), but I fear that it's following the same footsteps as Mozilla Persona maybe (lack of browser/userbase adoption)? :/