Ryan Baxter created SHINDIG-1944:
------------------------------------
Summary: Shared OAuth2 Tokens Do Not Work When Gadgets Are
Rendered Before Doing OAuth Dance
Key: SHINDIG-1944
URL: https://issues.apache.org/jira/browse/SHINDIG-1944
Project: Shindig
Issue Type: Bug
Affects Versions: 2.5.0, 2.5.0-update1
Reporter: Ryan Baxter
1. Configure 2 or more gadgets to use shared OAuth 2 tokens
2. Render both gadgets, notice you get prompted to authorize in both
3. Close one of the two gadgets
4. Do the OAuth dance in whatever gadget you did not close
5. Open the gadget you did close
6. Notice that you are still prompted to authorize the gadget when you should
not be
This happens because in step 2 an OAuth2Accessor is cached for both gadgets and
the cache key contains the gadget URL. The OAuth2Accessor is only removed from
the cache (in BasicOAuth2Request.fetch) when the OAuth2 dance is completed for
the gadget (causing OAuth2Accessor.isRedirecting() to return false). So when
you complete the OAuth dance in step 4 it only removed the OAuth2Accessor for
the one gadget and not for the other gadget using the shared token client. The
next time you render the other gadget it uses the OAuth2Accessor in the cache,
which does not have a refresh and access token, so the server thinks you must
do the OAuth dance.
One solution to this problem could be to change the key we are using for the
OAuth2Accessor cache. For a client that is using shared tokens we use the
service id and client id in place of the gadget URI in the cache key for the
access and refresh tokens. For the OAuth2Accessor cache this is not the case,
we use the gadget URI as part of the cache key. It seems to make sense that we
follow the same pattern for the OAuth2Accessor cache and use the service id and
client id in place of the gadget URI.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
