The URL to the gadget developers server will have up_xxx parameters for them to access the parameters.
As to "setprefs", these are done through rpc. Rpc will be supported, just like it is today - that is there will be an rpctoken on the URL (presumably the fragment portion). This rpctoken is used to validate themselves to the container. Handling of the rpctoken, and initial processing of the rpc call, is container side JS - independent of HTML or URL gadgets. Ultimate handling of the setpref service call is that of the container, which is NOT anything Shindig code is responsible for. I predict the JS code inside of the URL gadget (that which comes from the "libs" parameter) will be very similar to existing code. Generally I will remove calls that are not within the narrow specification for "URL gadget JS API". -----Original Message----- From: ilya.sht...@metavante.com [mailto:ilya.sht...@metavante.com] Sent: Tuesday, December 01, 2009 8:03 AM To: shindig-dev@incubator.apache.org Subject: RE: Next step towards URL gadgets - design proposal Perhaps I misunderstood your statement, but your Design Requirement 2 states: <quote> 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... </quote> If you're talking about the setpref feature, will the user have to pass session ID and some application-specific preferences as URL parameters? I thought it wouldn't be secure. From: "Weygandt, Jon" <jweyga...@ebay.com> To: <shindig-dev@incubator.apache.org> Date: 12/01/2009 09:53 AM Subject: RE: Next step towards URL gadgets - design proposal Not sure what you mean by "server side accessing of URL parameters"? -----Original Message----- From: ilya.sht...@metavante.com [mailto:ilya.sht...@metavante.com] Sent: Tuesday, December 01, 2009 7:47 AM To: shindig-dev@incubator.apache.org Subject: Re: Next step towards URL gadgets - design proposal 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" <jweyga...@ebay.com> To: <shindig-dev@incubator.apache.org> 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. --------------------------------------------------------------------- --------------------------------------------------------------------- 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. ---------------------------------------------------------------------
