On Tue, Nov 5, 2013 at 12:15 PM, Mike Pawlowski <mpaw...@ca.ibm.com> wrote:
>
>
> Hi
>
> ------------------------
> Problem
> ------------------------
>
> If the gadget content referenced by the gadget metadata is a protected /
> secured resource (i.e. requires the user to authenticate / authorize access
> to the resource), Shindig cannot render the gadget.
> Note: The gadget metadata itself is not a secured / protected resource
>
> The following error is shown in the gadget content area in place of the
> expected gadget contents.
> Unable to reach remote host. HTTP status 401
>
> The following error appears in the Shindig server log:
> [INFO ] The gadget at
> http://localhost:9081/examples/gadgets/make-request-metadata did not
> render. The following error occurred: Unable to reach remote host. HTTP
> status 401.
>
> e.g. Unprotected gadget metadata resource:
>
> <Module specificationVersion="2.0">
> <ModulePrefs title="My Gadget"
> ...
> </ModulePrefs>
>
> <OAuth2>
> <Service name="jazz"></Service>
> </OAuth2>
>
> <!-- Protected Resource -->
> <Content type="html" href="$
> {baseURL}/gadgets/protected-gadget-content.html" view="home, profile,
> canvas" />
> </Module>
>
> In this circumstance, Shindig doesn't invoke the configured OAuth 2.0 auth
> flow as expected for accessing the content (the gadget rendering request
> just fails outright).
>
> ------------------------
> Assumptions
> ------------------------
>
> (a) The gadget metadata resource must be unsecured / unprotected in order
> for Shindig to render a gadget
>
> ------------------------
> Questions
> ------------------------
>
> (1) Like assumption (a), is it a Shindig / OpenSocial gadget specification
> requirement that the gadget content be an unprotected / unsecured resource?
Yes I believe so.
>
> (2) Is it possible for Shindig to render gadgets whose content is a
> protected / secured resource?
Not that I know of. The main problem with fetching protected content
via OAuth 2.0 from the server is the OAuth dance. However there are
probably creative solutions for dealing with this if Shindig does not
currently have a token to use.
>
> e.g. Configuration option to turn on the OAuth 2.0 auth flow for protected
> content?
> e.g. Inject a Guice module that will handle the OAuth 2.0 auth flow for
> protected content?
>
> (3) Does Shindig only support the OAuth 2.0 auth flow for gadget
> makeRequest operations?
The gadget proxy (used for makeRequest) and the content proxy (used
for gadget resources) both support OAuth 2.0.
>
> (4) Is the solution outlined below, viable? Are there any alternative ways
> to invoke the OAuth 2.0 auth flow?
It seems viable however it is not the most efficient solution. I
guess at this point it is your only option, without making changes to
Shindig. I would at least try it and then revisit if making changes
to Shindig would be necessary.
>
> (5) Are there any built-in Shindig security features / mechanisms that we
> could utilize or leverage to handle our use case?
I don't believe so.
>
>
> ------------------------
> Our Solution
> ------------------------
>
> * Gadget metadata is an unprotected resource
> * Make the gadget content an unprotected resource
> * Gadget content is just a stub that does a gadget makeRequest on gadget
> load to GET the actual protected gadget content (HTML)
> * The makeRequest operation invokes the OAuth 2.0 auth flow for the user if
> required
> * After authorization / authentication, the protected gadget content is
> re-fetched and the response is simply inlined into the content area
>
>
>
> Thanks,
>
> Mike
