Hi Bryan, We've looked at this in Apache Wookie, which does use Widgets in a browser/webserver context. The general approach we've been discussing is similar to how Apache Shindig handles oAuth - to put the oAuth logic within the framework itself rather than in the Widget. So these issues around redirect and origin aren't a problem for the Widget but are instead part of how the Widget UA (aka Widget Runtime or WRT) implements oAuth. So oAuth would be a "feature" injected at runtime by the UA/WRT, and the Widget would have to access it via a JS API. These JS calls are then handled by the UA/WRT which has to handle the other "leg" of the oAuth call and render the authz screens presented for the user.
That said there are some issues around managing consumer secrets that are common to frameworks that we still have to address - as Widgets are portable and transparent you can't just encode the consumer secret in the widget's config.xml and distribute it on the web. Which means the framework has to manage them and request them for each Widget. Also, we don't have a standard for the JS API used for an oAuth feature; one option is to try to follow the same conventions as in OpenSocial[1] . (If you're interested, there is a discussion on this topic on the wookie-dev list [2]) S [1] http://opensocial-resources.googlecode.com/svn/spec/1.1/Core-Gadget.xml#gadgets.oauth.Popup [2] http://www.mail-archive.com/[email protected]/msg01922.html On 1 Nov 2010, at 12:19, Bryan Sullivan wrote: > Hi, > Can anyone point to an example of how to use HTTP redirect-based protocols > such as OAuth with widgets? There seem to be issues with the use of these > protocols due to the difference between widgets and browser-based webapps, in > particular with the two aspects: > widgets cannot access network resources unless an access request/dependency > to the domain is declared per the WARP spec. Thus any domain that is to be > used in a redirect-based protocol needs to be known up-front and explicitly > included per WARP. > for widgets, there is no “origin” or at least “base” that can be used in a > redirect-based protocol. All that widgets could expose for redirect purposes > are relative URIs for their resources. Thus redirect protocols/designs in > which one widget page makes a request which is intended to result in a > redirect to another widget page, will not work. > > An example of how to do this for widgets, e.g. a Twitter-enabled widget (as > Twitter uses OAuth) would be very helpful. > > It does seem that applications using XHR for this (as compared to web > links/anchors etc) would/should be in total control of the operation of XHR, > but they would need to handle all HTTP requests and responses (including > redirects). > > Apologies in advance if this request is not clear from a technical > perspective. > > Bryan
smime.p7s
Description: S/MIME cryptographic signature
