This is only for server configuration (setting up proxy endpoints, specifying file locations, etc.). You can *never* take arbitrary configuration parameters from an unknown source.
You can *never* inject an arbitrary file into an iframe either. It's like standardizing a XSS attack (especially problematic for type=url support). The only way to make open social work for a shared hosting solution is to either: a.) Standardize a container provided JsonRpc endpoint using the security token as a pass-through opaque token. or b.) Use interframe communication to get data from the parent page. All that aside, this is a problem for shared hosting providers, not for shindig; Shindig can't dictate what's best for these sites from an infrastructure standpoint. It's a problem for gmodules.com and possibly other sites like Ning that need to support multiple containers with the same iframe host -- this could be them hosting a fixed set of supported containers javascript, some whitelisting mechanism for the parent parameter, or whatever mechanism they come up with. In any case, it's beyond the scope of what we can really do here. On Feb 1, 2008 10:07 AM, Cassie <[EMAIL PROTECTED]> wrote: > I don't think this will work very nicely with people who don't want to > host > shindig themselves. Google's hosted shindig would be pretty worthless if > you > couldn't configure any of the js params... > > We also need to reconcile this with how opensocial works. In the > opensocial > land a new container implements one file, container.js. We need to provide > some way for people to get this file into the iframe easily with shindig. > > I think what some people do right now is wrap a call to a hosted shindig > and > inject their own code inside the iframe. (there are other solutions out > there too). It seems like there should be a better way. > > - Cassie > > > On Fri, Feb 1, 2008 at 2:17 AM, Kevin Brown (JIRA) <[EMAIL PROTECTED]> > wrote: > > > Support configuration variable substitution into resource files. > > ---------------------------------------------------------------- > > > > Key: SHINDIG-44 > > URL: https://issues.apache.org/jira/browse/SHINDIG-44 > > Project: Shindig > > Issue Type: New Feature > > Components: Features, Gadgets Server - Java, Gadgets Server - > PHP > > Reporter: Kevin Brown > > Assignee: Kevin Brown > > Priority: Minor > > > > > > Configuration is currently a major pain point for Shindig, especially > > since we frequently need configuration values passed down to javascript > > libraries. > > > > The solution I'm proposing is very simple: > > > > When shindig starts, load a configuration file containing key value > pairs. > > (implementation dependent) > > Whenever a file that might need configuration is read into memory, > > substitute these variables into the data. > > > > Example: > > > > features/core/feature.xml has a block like this currently: > > > > gadgets.io.init(proxyUrl: '/proxy?'); > > > > To use this, you have to modify the file every time you sync against svn > > just because you use a different path. That sucks. Instead, how about > this? > > > > gadgets.io.init(proxyUrl:'${io.proxyUrl}', jsonProxyUrl: '${ > > io.jsonProxyUrl}'); > > > > and a config file: > > io.proxyUrl = '/proxy?' > > io.jsonProxyUrl = '/proxy?js=1&' > > > > The [EMAIL PROTECTED] syntax should result in a parse error in all syntaxes > > that we care about, although it could conflict with open social's > activity > > stream templates so that might not be ideal. > > > > I think this should only be applicable inside of files loaded through > > JsFeatureLoader -- ideally, only feature.xml files and the javascript > that > > they reference should be affected, but we could potentially expand this > idea > > to other file types if it makes sense to do so. > > > > This proposal could serve as a full replacement for SHINDIG-22, or both > > could be used for situations where you need to calculate or validate at > run > > time. > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > >
