Tapestry

Working proof of concept Ruby script:

require 'rubygems'
require 'oauth2'
require 'yaml'
require 'sinatra'
require 'json'

CALLBACK_URL = 'http://localhost:8000/auth/open-humans/callback'
SCOPE = 'read write pgp'

def client
  OAuth2::Client.new(
    ENV['OH_KEY'],
    ENV['OH_SECRET'],
    :authorize_url => '/oauth2/authorize/',
    :token_url => '/oauth2/token/',
    :site => "http://open-humans-staging.herokuapp.com" 
  )
end

get '/' do
  redirect client.auth_code.authorize_url( :redirect_uri => CALLBACK_URL, :scope => SCOPE )
end

get '/auth/open-humans/callback' do
  code = params['code']
  token = client.auth_code.get_token( code, :redirect_uri => CALLBACK_URL, :scope => SCOPE )
  member_response = token.get '/api/member'
  "<pre>#{JSON.parse(member_response.body).to_yaml}</pre>" 
end

Right so it does the basics. There are areas where it could be improved and certainly where there is overlap with #4766 I will try to improve and genericize (any suggestions welcome), but in the name of getting this ready for Open Humans by Monday I'd like to get the review ball rolling.

Two important notes for getting it to work in dev or prod:

• <%= Section::OPEN_HUMANS %> needs to be added to the activated Tapestry sections in config.yml
• There are certain specific parameters for the new oauth service that an admin user needs to create before any user can send their huID to Open Humans. These have been communicated via email so if you as the reviewer weren't in the list just contact me and I'll send it you.

Also note that for the callback to work right now with the staging instance of Open Humans the port you use for running Tapestry should be 8000. This is hard-coded on the Open Humans end.

Now:

• The Open Humans integration feature can be turned on or off with a Tapestry "section"
• An admin can create and parameterize an Oauth Service that can be employed by the Open Humans integration
• Via the Third Parties page a user can, if an admin has created an Open Humans type of Oauth Service, create a token via the Open Humans website
• If the token has expired the user can refresh it
• If the token is valid and there are no registered huIDs the user can send it to Open Humans
• If the token is valid the user can see their registered huIDs, as well as delete them

reviewing b0fe47c

• in app/views/third_party/index.html.erb, line 20

  if defined? @open_humans_services && @open_humans_services.any?

does not guard against @open_humans_services being nil. If @open_humans_services is nil, it causes the code to blow up on line 24

@open_humans_services.each

• you seem to have inadvertently broken the existing third party studies pages; clicking through to a traditional third party now results in a permission denied, and I see that some of the code was removed from app/controllers/studies_controller.rb. You should also have a look at the instructions on the 'create collection event' page for researchers, when the '3rd party study' checkbox is checked.

• I wanted to test the functionality; can you e-mail me the parameters to use to create the oauth service in my test environment? I tried to use what Beau e-mailed, but I get 'invalid_client_id'. Maybe I'm doing something wrong.

As of 3781fa16462ae388fcd1ef542d94adf1bf89182b

• Should now guard against nil open humans services list, and also prevent it from ever being nil in the first place; added tests for this
• Collection events: never saw how those worked before: interesting; routes are quite confusing for those collection events and studies - not sure if I should have tried to re-use any of that functionality for this open humans interface; fixed the permission problem
• Emailed you my open humans oauth service configuration

Great work Phil, I think this looks good to merge!

Thank you Phil, I reviewed and have merged your code in the interest of expediency.

From request from Madeleine:

These changes are framed as two commits:

Commit 1: Text changes, and “hide” the Open Humans page
Implement text changes requested by PGP Harvard staff
Remove the link to the Open Humans page on the 3rd party activities page (i.e. make it “hidden”)
To be deployed to production without further PGP Harvard staff review
(Staff consensus is that the update is good, provided these changes are made.)

Commit 2: Add back the link to Open Humans page
Add link to Open Humans page on the 3rd party activities page. It should show up as the first link in the listed activities, rather than at the end.

Commit 1 changes, in detail:

Temporarily remove the link to the Open Humans page from the 3rd party activities page (i.e. comment it out).

Add the following sentence to the end of the description of Open Humans, as a new paragraph:

Additional information about Open Humans can be found at its website: http://openhumans.org

Update the text above the pre-authorization button to say:

The link below will take you to the Open Humans website where you will be able to create an account. Once you have an account, you'll be returned to the PGP website, where you must approve the export of huID to your Open Humans account.

Update the text above the post-authorization, pre-huID sharing button to say:

Your huID is not currently shared with Open Humans. Adding it will trigger an import of your public PGP Harvard data into your Open Humans account.

Update the text above the post-authorization, post-huID sharing button to say:

"Your huID is registered with Open Humans. Removing this will NOT remove data sets imported by Open Humans; you can manage those separately in your Open Humans account."

Update the post-authorization, post-huID sharing button from "Delete huID" to say:

"Remove huID from Open Humans"

Commit 2 changes, in detail:

Add back the link to the Open Humans page from the 3rd party activities page.

Move it to appear as the first item in the listed activities, rather than the last.

I've committed everything for the first step she outlines. The second step will involve reversing c9adde3a and then putting the Open Humans link at the top of the study list.