Feature #6961
closedSimplify Tapestry/Open Humans account link flow
100%
Description
Wording changes
*Old wording*Explanatory text: "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."
Button: "Add authorization"
*New wording*Explanatory text: "The link below will take you to the Open
Humans website. You'll be able to create an account there. We will send
Open Humans your participant identifier (huABC123), enabling transfer of
your public data, once you finalize this data transfer on the Open Humans
website."
Button: "Share my data with Open Humans"
*New wording once the user has authorized Open Humans*The button is not
shown and the explanatory text becomes: "You've connected Open Humans to
your PGP account and we've shared your participant ID. If you would like to
remove this data and connection from Open Humans, you'll need to do so
within your account on <a href="
https://www.openhumans.org/member/me/connections/">Open Humans</a>."
Procedural changes
The "origin" parameter
A new querystring parameter, "origin", will be sent to Open Humans in the
initial request to /oauth2/authorize/. PGP will also accept the "origin"
querystring parameter on the PGP side and forward it through to Open Humans
via the request to /oauth2/authorize/. This parameter is also sent to
OAuth2 callback on the PGP side.
Immediate sending of huID
The huID will be sent immediately after the OAuth2 callback is called (
https://my.pgp-hms.org/auth/open-humans/callback).
Conditional redirect based on "origin" parameter
Depending on the value of the origin parameter the user will be redirected
either back to Open Humans (if the origin is "open-humans") or to the PGP
Open Humans participation page (if the origin is not present or is anything
but "open-humans"; we suggest using the string "external")
For example:
User starts on Open Humans
1. Open Humans sends user to
https://my.pgp-hms.org/open_humans/participate?origin=open-humans
2. User clicks button on PGP site
3. PGP sends user to https://www.openhumans.org/oauth2/authorize/?(OAuth2
parameters)&origin=open-humans (using the value of "origin" that the page
was loaded with)
4. If the user authorizes then the user is redirected back to the OAuth2
callback endpoint at
https://my.pgp-hms.org/auth/open-humans/callback?(OAuth2
parameters)&origin=open-humans
5. PGP then sends the huID to Open Humans and redirects the user back to
https://www.openhumans.org/member/me/research-data/
User starts on PGP
1. User clicks button on PGP site
2. PGP sends user to https://www.openhumans.org/oauth2/authorize/?(OAuth2
parameters)&origin=external (using "external" because the page was not
loaded with an origin specified)
3. If the user authorizes then the user is redirected back to the OAuth2
callback endpoint at
https://my.pgp-hms.org/auth/open-humans/callback?(OAuth2
parameters)&origin=external
4. PGP then sends the huID to Open Humans and sends the user to
https://my.pgp-hms.org/open_humans/participate where they see the "You've
connected Open Humans to your PGP account" text
Let me know if any of this needs clarification. :)
And here's the flowchart/mockup URL again if that's useful:
https://personalgenomes.mybalsamiq.com/projects/update-pgp/prototype/Updating%20PGP%20Harvard%20connection?key=30090b9af
29d405942c7403dec78fb37c4ff5b62
Thanks,
Beau
Updated by Ward Vandewege over 9 years ago
- Subject changed from Simplify Tapestry/Open Humans link flow to Simplify Tapestry/Open Humans account link flow
Updated by Ward Vandewege over 9 years ago
- Status changed from New to In Progress
Updated by Tom Clegg over 9 years ago
In OpenHumansController#disconnect_worker, this comment sounds like a good idea but it doesn't seem to be implemented this way:
# We deliberately return success based on the outcome of the local token revocation, only.
# That's the only thing we can control anyway, and also what drives all logic on our end.
It looks like the only case where success ends up false
is the one where both the OpenHumans remote API call and the local revocation fail.
I suppose the trouble is that [a] if the "dissociate" API calls fail, and we revoke our token, we have no way to retry the "dissociate" API; but [b] if "dissociate" fails, and we don't revoke our token, then it's impossible for a user to revoke permission as long as the "dissociate" API fails.
The token.revoke!
call currently looks like it deletes the token if the token is authorized, but never calls the remote revocation URL for OAuth2 tokens. Since we more or less rely on this being the behavior, I suggest changing token.revoke!
to token.destroy
here.
I'm a bit confused by the testing situation: It looks like there are no test updates in this branch (I'm at cdabc77). The existing "delete" test passes, even though the corresponding route and action method have disappeared. What am I missing?
Updated by Ward Vandewege over 9 years ago
Tom Clegg wrote:
In OpenHumansController#disconnect_worker, this comment sounds like a good idea but it doesn't seem to be implemented this way:
[...]
It looks like the only case where success ends up
false
is the one where both the OpenHumans remote API call and the local revocation fail.I suppose the trouble is that [a] if the "dissociate" API calls fail, and we revoke our token, we have no way to retry the "dissociate" API; but [b] if "dissociate" fails, and we don't revoke our token, then it's impossible for a user to revoke permission as long as the "dissociate" API fails.
The
token.revoke!
call currently looks like it deletes the token if the token is authorized, but never calls the remote revocation URL for OAuth2 tokens. Since we more or less rely on this being the behavior, I suggest changingtoken.revoke!
totoken.destroy
here.
I've covered all this in caa77f0a
Updated by Ward Vandewege about 9 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset 931256c274b55944a85735f9c34d147b37ee7a10.