The ability to handle URL gadgets "out of the box" is critical if we want
Shindig to become an enterprise asset, so I applaud the effort. This said,
does anyone have plans to address how URL gadgets will work in a secure
environment? I don't think " server side accessing of URL
parameters" plays very well here. The scenario is further complicated by
the fact that Shindig will frequently be used as a "service" rather than
co-hosted with the application. Would be interesting to hear how people
address these needs or if there are any plans to solve this once and for
all in Shindig.
Thanks,
Ilya
From: "Weygandt, Jon" <[email protected]>
To: <[email protected]>
Date: 11/25/2009 01:52 PM
Subject: Next step towards URL gadgets - design proposal
A proposal for review and comment...
I would like to implement section 3.1.3(6)(c)
http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadget
s-API-Specification.html#process. This will not be a complete
implementation for URL gadgets, but takes Shindig one step closer to the
specification, and will provide a platform for which server implementers
can experiment with URL functionality.
Design requirements:
================
1) URL gadget developers require features that they cannot easily
replace, such as rpc, dynamic-height, set-title, views, etc...
2) URL gadget developers do not require features like Prefs.get*, log,
etc...
*) Some of these they would never use
*) Prefs methods are replaced with server side accessing of URL
parameters
3) Same origin policy makes implementing makeRequest, dataRequest
impractical
*) Server side calls to REST and RPC APIs are the alternative
Design proposal
=============
libs parameter
This will be a variant of the /gadgets/js/rpc.js. It will fetch the
URL-Gadget-Side JS necessary.
Feature libraries, JS Servlet, Rendering Context
To support a reduced set of JavaScript, and maybe even a different set
of JS the changes will start with introducing a new
RenderingContext.URLGADGET. "c=2" for the JSServlet. Down to the
feature.xml file having a new tag <urlgadget>
Some of the individual feature JS may be split apart to support
inclusion in gadget context separately from urlgadget context.
Currently the rendering does a redirect as part of the ifr call. I will
also introduce an option into shindig.properties, whereby the metadata
call will return the external URL as part of iframeurl, instead of the
ifr url with a redirect.
Open Issues
==========
The spec does not address how one determines the "servers JavaScript
request handler path". I don't propose to address this as part of this
effort, since few containers will actually support URL gadgets, the
developer will pretty much know who they are targeting.
The issue of the gadget developer putting "foreign" JavaScript on their
page introduces cross site scripting concerns for them. This is also
beyond the scope of this patch, but would probably be addressed by
signing the request and developers whitelisting the servers that they
support.
Comments
=========
I would be doing the changes to the Java side of Shindig.
As to the additional tag in features.xml with respect to PHP, it appears
the PHP code (GadgetFeatureResigtry.php) is similar to the Java side, it
will simply ignore the new tag.
---------------------------------------------------------------------
The information contained in this message is proprietary and/or
confidential. If you are not the intended recipient, please: (i) delete
the message and all copies; (ii) do not disclose, distribute or use the
message in any manner; and (iii) notify the sender immediately. In
addition, please be aware that any message addressed to our domain is
subject to archiving and review by persons other than the intended
recipient. Thank you.
---------------------------------------------------------------------
