Thanks. I'll investigate option 4. On Apr 26, 2012, at 2:50 PM, "A Clarke" <[email protected]> wrote:
> 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 > >
