Thanks for the response, Ryan. RE: Question (2)
While trying to learn more about Shindig's content proxy that you mentioned, I noticed that there appears to be a provision for Shindig to render protected gadget content in the OpenSocial Core Gadget Specification 2.5.0: See: http://opensocial-resources.googlecode.com/svn/spec/2.5/Core-Gadget.xml#ContentElement @href "If @type is "html", the Container MUST proxy (Section 6) the current content section. Discussion [Issue-1173]" See: http://opensocial-resources.googlecode.com/svn/spec/2.5/Core-Gadget.xml#ProxiedContent "the container MUST issue an HTTP request to the URI specified by the href attribute following the rules defined in gadgets.io.makeRequest (Section 13.2.1.3)." Unless I'm reading the spec incorrectly - which is entirely possible - I should be able to specify additional Content element attributes that map to auth related makeRequest parameters e.g. <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" authz="OAUTH2" oauth_service_name="jazz" refresh_interval="0" /> </Module> I tried this and of course this didn't work for me on the first try : ) (I need to debug the underlying Shindig source to figure out what is going wrong) Using the above gadget metadata, I'm getting a 403 instead of a 401 response code instead: 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 403. Is my spec interpretation correct? Is the above alternate solution viable? e.g. Should Shindig support the OAuth2 auth flow for rendering gadget content? e.g. Is there something wrong with the Content element mark-up I specified in the above sample gadget metadata? Mike From: Ryan Baxter <rbaxte...@gmail.com> To: "dev@shindig.apache.org" <dev@shindig.apache.org>, Date: 2013-11-06 10:39 AM Subject: Re: Is it possible for Shindig to render gadgets whose content is a protected / secured resource? 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
