External OpenSocial Gadgets and Trusted Application Link

[Anton Litvinenko]

We would like to show external open social gadgets (from the tool we develop ourselves) on JIRA dashboards and Confluence pages. At the moment, these gadgets use OAuth authentication (configured via application link).

What bothers us is that each such gadget requires performing a separate authentication and granting permission. On the other hand we saw that if we add a JIRA as a trusted app to the Confluence and then add external opensocial gadgets to Confluence page then one doesn't need to perform an authentication for each gadget.

We are wondering if such behavior is achievable for custom (not Atlassian) products. We've found the following blog post series to be helpful: http://blogs.atlassian.com/developer/2011/06/unified_applinks_integration_without_the_hassle_-_part_1.html

But they don't say if external open social gadgets would work with such solution.

Questions:

• Would implementing a custom ApplicationLinkService be a correct way of solving our problem?
• How would we need to modify our open social gadgets to take advantage of the custom ApplicationLinkService?
• will it be done automatically using url matching or service provider name matching?
• do we need to use Atlassian open social API for that or we might stick with official open social API?
• would it be possible for gadgets to fall back silently to typical OAuth auth whenever a custom trusted application link is not configured and the usual OAuth application link is used instead?

[Raimonds Simanovskis]

I have managed to create the following solution to avoid authentication of each individual external gadget which is included in JIRA dashboards or Confluence pages.

• When my application is receiving OAuth request token request from JIRA/Confluence then I am storing also OAuth authorization header attribute opensocial_viewer_id (which is JIRA or Confluence user name) together with issues request token.
• After user authorizes request token and corresponding OAuth2 access token is created then I am also storing opensocial_viewer_id with it.
• When I receive second OAuth request token request from JIRA/Confluence (when user is including next gadget) then I search if within last 10 minutes I have created access token from the same source consumer with the same opensocial_viewer_id. If I have found such recently created access token for the same user then I mark newly created request token as authorized.
• In gadget JavaScript when doing gadgets.io.makeRequest and receiving response.oauthApprovalUrl (which means that I should show OAuth authorization popup) and retry one more time the same request - in case of second gadget if I marked created request token as authorized then access token request will succeed. If I get OAuth error for this second gadgets.io.makeRequest (which means that request token was not authorized) then I show OAuth authorization popup.

Using this solution from users perspective if they add several gadgets then they will need to authorize just the first one and the next will be authorized automatically. After 10 minutes since the last gadget was added if they will try to add new gadget then they will need to authorize it again. If you need more clarification about some step then please let me know :)

I implemented similar solution also for including my gadgets in Google Sites but there I was able to solve also my additional problem that I described in my first comment. Google Sites in OAuth header include also opensocial_app_id attribute which is unique ID for each gadget instance in particular page. Which means that I could implement that when I receive new OAuth request token request then I search if I have already access token created for this particular opensocial_app_id - if yes then I will return the same original access token that I already stored for this opensocial_app_id. Which means that if some Google Sites user created page and included my gadget and authorized it then he/she can share this page with others and all others will see page with gadget which will use original authorized access token.

In case of JIRA and Confluence unfortunately opensocial_app_id contains the same value as opensocial_app_url which is gadget specification XML URL. So unfortunately I cannot identify particular instance of gadget in JIRA dashboard or Confluence page.

So my question to Atlassian is would it be possible to change opensocial_app_id to be unique instance ID of gadget in particular page (like it is in case of Google Sites)? It would be very helpful to implement access token sharing also for JIRA dashboards and Confluence pages.

[Raimonds Simanovskis]

Found in OpenSocial Gadget spec that more correct approach would be to provide additional opensocial_instance_id OAuth header attribute which uniquely identifies gadget application instance http://opensocial-resources.googlecode.com/svn/spec/2.0.1/Core-Gadget.xml#SignedFetch

Would it be possible to add it to future JIRA/Confluence releases?

[Raimonds Simanovskis]

I am implementing similar external OpenSocial gadget as well which will publish content from external application using OAuth authentication. In my case I am wondering if it is possible that

• one JIRA user creates JIRA dashboard and inserts external gadget and authenticates it using OAuth and with his/her external application credentials
• then this users shares this dashboard with other JIRA users
• when other users visit this shared dashboard then JIRA would use stored OAuth access token of the user who created this shared dashboard

Currently it seems that JIRA gadget container stores OAuth access tokens separately for each JIRA user and does not allow such OAuth access token sharing. Or are there any workaround how to achieve it?