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.
---------------------------------------------------------------------
