Doug, There's three options you can try out easily, none of these worked for us so we did option 4 and extended the OAuth2 Consumer and Provider to seamlessly suppress the dance.
1) Client Credentials. The authorization code flow hinges on the dance occuring, but client credentials works without the dance. It requires that your target provider support client credentials. The problem we encountered here was that there was no suitable way to assert the user's identity in the client credentials flow. 2) Shared Client. This dropped recently with Jira 1731. It allows you to specify that all gadgets bound to a client share the same access and refresh tokens. Meaning the user only has to go through the dance once. 3) Custom implementation of shared clients. You can write your own version of shared clients that returns the same token for every gadget in your OAuth2Persister. This of course requires that a valid access token is available, either by opting in once or having some custom logic to prepoluate a token. 4) Customize your provider and customize your consumer to work together. The approach that we eventually took. On Thu, Apr 26, 2012 at 11:58 AM, daviesd <[email protected]> wrote: > A quick yes or no question which is plaguing us right now. > > Does an oauth2 enabled gadget ALWAYS have to do the popup oauth2 dance? In > other words, there is no way to make a service call without first having a > user click the authorization url and the authorization server redirecting > the browser back to the redirect uri. Correct? Is there a way to do this > automatically (but then I suspect you¹d get a browser warning). And if you > don¹t share the access token across multiple services, then you¹d have to > go > through the oauth2 dance for each type of service??? > > Ok, maybe not a simple yes/no answer. :) > > doug >
