I disagree about it not being the scope of this project. Providing a way for shindig to be configured when it is hosted by an outside party definitely seems like something we should build. And I'm not talking about arbitrary params or arbitrary file injection at all. I can even use some very specific examples. Lets take skins and views.
The site which contains shindig hosted gadgets in iframes needs to be able to say what views it supports, in this case only fullpage and dashboard. It also needs to be able to tell the gadget that its bgColor should be black and fontColor should be red. Right now we have a line in the features/views/feature.xml file which calls gadgets.views.init(with config params). It would be great if we figured out a way for those config params to come from the site containing the gadgets.. instead of being hardcoded in the shindig server. I can even think of a situation where a site running its own shindig would need to be able to do this. Perhaps you want to change the background color depending on which profile page you are on (ie a super user configed site like myspace, or even hi5 has skins). They can't change config parameters in shindig for every page, it would be great if there was an easy way for them to give logic to the iframe somehow. Like we have mentioned before there are a couple ways for doing this, ifpc and passing params on the iframe url are two of them. So, perhaps we should convert the views logic to use those or some other method. I'm just arguing against what the bug is proposing because I think it may lock us down too much. I hope that all makes sense, it got a little long :) - Cassie On Fri, Feb 1, 2008 at 11:08 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > 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. > > > > > > > > >
