On Wed, Nov 6, 2013 at 1:04 PM, Mike Pawlowski <mpaw...@ca.ibm.com> wrote:
> 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-metadatadid > not render. The following error occurred: Unable to reach remote host. > HTTP status 403. > > Is my spec interpretation correct? > Yup your interpretation is correct. > > > Is the above alternate solution viable? > e.g. Should Shindig support the OAuth2 auth flow for rendering gadget > content? > It should support it, but it was never implemented. There are other scenarios like this where the spec says you can use OAuth to make requests for things but in reality Shindig only supports OAuth for gadgets.io.makeRequest. > > e.g. Is there something wrong with the Content element mark-up I specified > in the above sample gadget metadata? > It looks right to me. > > > > Mike > > > > > [image: Inactive hide details for Ryan Baxter ---2013-11-06 10:39:37 > AM---On Tue, Nov 5, 2013 at 12:15 PM, Mike Pawlowski <mpawlow@ca.i]Ryan > Baxter ---2013-11-06 10:39:37 AM---On Tue, Nov 5, 2013 at 12:15 PM, Mike > Pawlowski <mpaw...@ca.ibm.com> wrote: > > > 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 > > >
