I'm thinking the answer WRT the security token is to use a short lived token
on the gagdet URL and swap that out for a longer lived token on the Shindig
side -- but it still seems that there would be at least some small window on
page load where the short lived token could still be sniffed/used by another
gadget on the page for evil.
As for the RPC token -- is that used for anything sensitive? Do I need to
be concerned about it being sniffed by other gadgets on the page?
And finally -- I'm still trying to understand what I need to do on the
Shindig side WRT locked domain support. I see options in the shindig config
file to enable locked domain, but it seems like most of the work would be on
the container side in generating the iframe url's on unique domains...
Please see the rest of this thread for more details.
Any feedback at all on this would be appreciated...
Thanks!
--Jesse
On Fri, Dec 4, 2009 at 10:46 AM, Jesse <jss9920@gmail.com> wrote:
> I've experimented a bit more with locked domain by just setting up my
> container to prepend a counter to the iframe url for each gadget -- so I end
> up with iframe urls which look something like:
>
> 1.gadgets.mydomain.com/gadgets/ifr?url=...&st=...&rpctoken=...&...
> 2.gadgets.mydomain.com/gadgets/ifr?url=...&st=...&rpctoken=...&...
> 3.gadgets.mydomain.com/gadgets/ifr?url=...&st=...&rpctoken=...&...
> ...
>
> (I realize that the urls should stay consistent across page renders for the
> same gadget, but for testing purposes I just wanted to get the gadgets on
> unique domains)
>
> Everything seems to work just fine with this setup, and I do indeed see
> additional sandboxing happening in the browser. I tested this by doing some
> experimentation in FireFox using FireBug -- before implementing the locked
> domain changes all of these statements in FireBug execute successfully:
>
> cd($("remote_iframe_0").contentWindow); //change FireBug's context to the
> window of one of the gadgets
> console.log(document.location); //make sure the context is now what I
> think it should be
> var otherWindow = window.parent.frames["remote_iframe_1"]; //grab a
> reference to the window of another gadget
> console.log(otherWindow.location); //log its location to be sure I have a
> hold of the iframe I think I do
> console.log(otherWindow.document.getElementById('someElement').textContent);
> //log out the content of an element in the other gadget
>
> and as soon as I implement locked domain as described above, the last
> statement fails with a security exception (as expected).
>
> But I'm still left with a few questions...
>
> 1) Even with the gadgets rendering on their own domains, I can still get to
> the location property of other gadgets on the page, which means I can parse
> out things like the security tokens and rpc tokens -- doesn’t that mean one
> gadget can still spoof another? How do other containers handle this?
>
> 2) I'm still trying to understand what all the locked domain code in
> Shindig is for... I can see how some of it would be useful in my container
> (like the logic in HashLockedDomainService that generates the iframe url
> based on a hash of the gadget url) -- so is that why it’s there? To be use
> on the container side? But then I also see methods in the
> LockedDomainService interface that definitely seem Shindig specific like
> isSafeForOpenProxy and gadgetCanRender, so I'm sure there must be more to it
> that I'm not understanding... I've spent a bunch of time digging in the
> Shindig codebase and searching through the mailing list looking for tidbits
> but haven’t made much progress so far...
>
> Any help or pointers would be greatly appreciated!
> On Thu, Dec 3, 2009 at 9:55 AM, jss9920 <jss9920@gmail.com> wrote:
>
>> I would like to start rendering my gadgets on unique locked domains but am
>> getting a bit confused about where to start...
>>
>> Since the container generates the gadget iframe urls, it would seem that
>> implementing locked domain would be a container side affair, but I see
>> configuration options for locked domain support in the shindig container.js
>> file and I also see associated Java classes that do a lot of locked domain
>> work in the Shindig codebase (Java Shindig 1.0 release)...
>>
>> So is there actually work that needs to be done on both the container side
>> and the Shindig side to enable locked domain gadgets?
>>
>> Any pointers on how to get started (even high level) would be helpful and
>> much appreciated.
>>
>> Thanks!
>>
>
>
Is there a use-case where you want to force javascript to be inlined?
Obviously this CL has a global on/off switch for that behavior, so you're
safe there plus libs always take precedence.
The way I see it, requiring the front-end to compute the libs parameter
requires that it have much more information about the gadget metadata that
it doesn't necessarily need.
On Mon, Dec 7, 2009 at 11:29 AM, John Hjelmstad <fargo@google.com> wrote:
> FWIW:
>
> While I'm fine w/ this CL as implemented, I'll note that we've dealt with
> this at the URL generation side rather than gadget rendering side, as it
> affords more flexibility on a render-by-render basis.
>
> 2c,
> John
>
> On Mon, Dec 7, 2009 at 6:58 PM, <lindner@apache.org> wrote:
>
> > Author: lindner
> > Date: Mon Dec 7 18:58:24 2009
> > New Revision: 888082
> >
> > URL: http://svn.apache.org/viewvc?rev=888082&view=rev
> > Log:
> > SHINDIG-1227 | Patch from chirag shah | Allow JavaScript features
> required
> > by a gadget to be externalized on demand
> >
> > Modified:
> > incubator/shindig/trunk/java/common/conf/shindig.properties
> >
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java
> >
> > Modified: incubator/shindig/trunk/java/common/conf/shindig.properties
> > URL:
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/common/conf/shindig.properties?rev=888082&r1=888081&r2=888082&view=diff
> >
> >
> ==============================================================================
> > --- incubator/shindig/trunk/java/common/conf/shindig.properties
> (original)
> > +++ incubator/shindig/trunk/java/common/conf/shindig.properties Mon Dec
> 7
> > 18:58:24 2009
> > @@ -63,6 +63,10 @@
> > #shindig.gadget-rewrite.default-forced-libs=core:core.io
> > shindig.gadget-rewrite.default-forced-libs=
> >
> > +#
> > +# Allow supported JavaScript features required by a gadget to be
> > externalized on demand
> > +shindig.gadget-rewrite.externalize-feature-libs=false
> > +
> > # Configuration for image rewriter
> > shindig.image-rewrite.max-inmem-bytes = 1048576
> > shindig.image-rewrite.max-palette-size = 256
> >
> > Modified:
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java
> > URL:
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java?rev=888082&r1=888081&r2=888082&view=diff
> >
> >
> ==============================================================================
> > ---
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java
> > (original)
> > +++
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java
> > Mon Dec 7 18:58:24 2009
> > @@ -41,6 +41,7 @@
> > import org.apache.shindig.gadgets.spec.ModulePrefs;
> > import org.apache.shindig.gadgets.spec.UserPref;
> > import org.apache.shindig.gadgets.spec.View;
> > +import org.apache.commons.lang.StringUtils;
> > import org.w3c.dom.Document;
> > import org.w3c.dom.Element;
> > import org.w3c.dom.Node;
> > @@ -99,6 +100,8 @@
> > protected final RpcServiceLookup rpcServiceLookup;
> > protected Set<String> defaultExternLibs = ImmutableSet.of();
> >
> > + protected Boolean externalizeFeatures = false;
> > +
> > /**
> > * @param messageBundleFactory Used for injecting message bundles into
> > gadget output.
> > */
> > @@ -117,11 +120,16 @@
> >
> > @Inject
> > public void
> >
> setDefaultForcedLibs(@Named("shindig.gadget-rewrite.default-forced-libs")String
> > forcedLibs) {
> > - if (forcedLibs != null && forcedLibs.length() > 0) {
> > + if (StringUtils.isNotBlank(forcedLibs)) {
> > defaultExternLibs =
> > ImmutableSortedSet.copyOf(Arrays.asList(forcedLibs.split(":")));
> > }
> > }
> >
> > + @Inject(optional = true)
> > + public void
> >
> setExternalizeFeatureLibs(@Named("shindig.gadget-rewrite.externalize-feature-libs")Boolean
> > externalizeFeatures) {
> > + this.externalizeFeatures = externalizeFeatures;
> > + }
> > +
> > public void rewrite(Gadget gadget, MutableContent mutableContent)
> throws
> > RewritingException {
> > // Don't touch sanitized gadgets.
> > if (gadget.sanitizeOutput()) {
> > @@ -215,40 +223,37 @@
> > // TODO: If there isn't any js in the document, we can skip this.
> > Unfortunately, that means
> > // both script tags (easy to detect) and event handlers (much more
> > complex).
> > GadgetContext context = gadget.getContext();
> > - String externParam = context.getParameter("libs");
> >
> > - // List of extern libraries we need
> > - Set<String> extern;
> > + // Set of extern libraries requested by the container
> > + Set<String> externForcedLibs = defaultExternLibs;
> >
> > // gather the libraries we'll need to generate the extern libs
> > - if (externParam == null || externParam.length() == 0) {
> > - // Don't bother making a mutable copy if the list is empty
> > - extern = (defaultExternLibs.isEmpty()) ? defaultExternLibs :
> > - Sets.newTreeSet(defaultExternLibs);
> > - } else {
> > - extern = Sets.newTreeSet(Arrays.asList(externParam.split(":")));
> > + String externParam = context.getParameter("libs");
> > + if (StringUtils.isNotBlank(externParam)) {
> > + externForcedLibs =
> > Sets.newTreeSet(Arrays.asList(externParam.split(":")));
> > }
> > -
> > - if (!extern.isEmpty()) {
> > - String jsUrl = urlGenerator.getBundledJsUrl(extern, context);
> > +
> > + if (!externForcedLibs.isEmpty()) {
> > + String jsUrl = urlGenerator.getBundledJsUrl(externForcedLibs,
> > context);
> > Element libsTag =
> headTag.getOwnerDocument().createElement("script");
> > libsTag.setAttribute("src", jsUrl);
> > headTag.appendChild(libsTag);
> > }
> > -
> > +
> > List<String> unsupported = Lists.newLinkedList();
> > - List<FeatureResource> externResources =
> > - featureRegistry.getFeatureResources(gadget.getContext(), extern,
> > unsupported);
> > +
> > + List<FeatureResource> externForcedResources =
> > + featureRegistry.getFeatureResources(context, externForcedLibs,
> > unsupported);
> > if (!unsupported.isEmpty()) {
> > LOG.info("Unknown feature(s) in extern &libs=: " +
> > unsupported.toString());
> > unsupported.clear();
> > }
> > -
> > +
> > // Get all resources requested by the gadget's requires/optional
> > features.
> > Map<String, Feature> featureMap =
> > gadget.getSpec().getModulePrefs().getFeatures();
> > List<String> gadgetFeatureKeys =
> > Lists.newArrayList(gadget.getDirectFeatureDeps());
> > List<FeatureResource> gadgetResources =
> > - featureRegistry.getFeatureResources(gadget.getContext(),
> > gadgetFeatureKeys, unsupported);
> > + featureRegistry.getFeatureResources(context, gadgetFeatureKeys,
> > unsupported);
> > if (!unsupported.isEmpty()) {
> > List<String> requiredUnsupported = Lists.newLinkedList();
> > for (String notThere : unsupported) {
> > @@ -260,13 +265,33 @@
> > if (!requiredUnsupported.isEmpty()) {
> > throw new
> > UnsupportedFeatureException(requiredUnsupported.toString());
> > }
> > + }
> > +
> > + // Inline or externalize the gadgetFeatureKeys
> > + List<FeatureResource> inlineResources = Lists.newArrayList();
> > + List<String> allRequested = Lists.newArrayList(gadgetFeatureKeys);
> > +
> > + if (externalizeFeatures) {
> > + Set<String> externGadgetLibs =
> > Sets.newTreeSet(featureRegistry.getFeatures(gadgetFeatureKeys));
> > + externGadgetLibs.removeAll(externForcedLibs);
> > +
> > + if (!externGadgetLibs.isEmpty()) {
> > + String jsUrl = urlGenerator.getBundledJsUrl(externGadgetLibs,
> > context);
> > + Element libsTag =
> > headTag.getOwnerDocument().createElement("script");
> > + libsTag.setAttribute("src", jsUrl);
> > + headTag.appendChild(libsTag);
> > + }
> > + } else {
> > + inlineResources.addAll(gadgetResources);
> > }
> > -
> > +
> > // Calculate inlineResources as all resources that are needed by the
> > gadget to
> > // render, minus all those included through externResources.
> > // TODO: profile and if needed, optimize this a bit.
> > - List<FeatureResource> inlineResources =
> > Lists.newArrayList(gadgetResources);
> > - inlineResources.removeAll(externResources);
> > + if (!externForcedLibs.isEmpty()) {
> > + allRequested.addAll(externForcedLibs);
> > + inlineResources.removeAll(externForcedResources);
> > + }
> >
> > // Precalculate the maximum length in order to avoid excessive
> garbage
> > generation.
> > int size = 0;
> > @@ -280,8 +305,6 @@
> > }
> > }
> >
> > - List<String> allRequested = Lists.newArrayList(gadgetFeatureKeys);
> > - allRequested.addAll(extern);
> > String libraryConfig =
> > getLibraryConfig(gadget,
> > featureRegistry.getFeatures(allRequested));
> >
> > @@ -348,8 +371,7 @@
> > }
> >
> > addHasFeatureConfig(gadget, config);
> > - addOsapiSystemListMethodsConfig(gadget.getContext().getContainer(),
> > config,
> > - gadget.getContext().getHost());
> > + addOsapiSystemListMethodsConfig(context.getContainer(), config,
> > context.getHost());
> > addSecurityTokenConfig(context, config);
> > return "gadgets.config.init(" + JsonSerializer.serialize(config) +
> > ");\n";
> > }
> >
> >
> >
>
FWIW:
While I'm fine w/ this CL as implemented, I'll note that we've dealt with
this at the URL generation side rather than gadget rendering side, as it
affords more flexibility on a render-by-render basis.
2c,
John
On Mon, Dec 7, 2009 at 6:58 PM, <lindner@apache.org> wrote:
> Author: lindner
> Date: Mon Dec 7 18:58:24 2009
> New Revision: 888082
>
> URL: http://svn.apache.org/viewvc?rev=888082&view=rev
> Log:
> SHINDIG-1227 | Patch from chirag shah | Allow JavaScript features required
> by a gadget to be externalized on demand
>
> Modified:
> incubator/shindig/trunk/java/common/conf/shindig.properties
>
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java
>
> Modified: incubator/shindig/trunk/java/common/conf/shindig.properties
> URL:
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/common/conf/shindig.properties?rev=888082&r1=888081&r2=888082&view=diff
>
> ==============================================================================
> --- incubator/shindig/trunk/java/common/conf/shindig.properties (original)
> +++ incubator/shindig/trunk/java/common/conf/shindig.properties Mon Dec 7
> 18:58:24 2009
> @@ -63,6 +63,10 @@
> #shindig.gadget-rewrite.default-forced-libs=core:core.io
> shindig.gadget-rewrite.default-forced-libs=
>
> +#
> +# Allow supported JavaScript features required by a gadget to be
> externalized on demand
> +shindig.gadget-rewrite.externalize-feature-libs=false
> +
> # Configuration for image rewriter
> shindig.image-rewrite.max-inmem-bytes = 1048576
> shindig.image-rewrite.max-palette-size = 256
>
> Modified:
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java
> URL:
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java?rev=888082&r1=888081&r2=888082&view=diff
>
> ==============================================================================
> ---
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java
> (original)
> +++
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java
> Mon Dec 7 18:58:24 2009
> @@ -41,6 +41,7 @@
> import org.apache.shindig.gadgets.spec.ModulePrefs;
> import org.apache.shindig.gadgets.spec.UserPref;
> import org.apache.shindig.gadgets.spec.View;
> +import org.apache.commons.lang.StringUtils;
> import org.w3c.dom.Document;
> import org.w3c.dom.Element;
> import org.w3c.dom.Node;
> @@ -99,6 +100,8 @@
> protected final RpcServiceLookup rpcServiceLookup;
> protected Set<String> defaultExternLibs = ImmutableSet.of();
>
> + protected Boolean externalizeFeatures = false;
> +
> /**
> * @param messageBundleFactory Used for injecting message bundles into
> gadget output.
> */
> @@ -117,11 +120,16 @@
>
> @Inject
> public void
> setDefaultForcedLibs(@Named("shindig.gadget-rewrite.default-forced-libs")String
> forcedLibs) {
> - if (forcedLibs != null && forcedLibs.length() > 0) {
> + if (StringUtils.isNotBlank(forcedLibs)) {
> defaultExternLibs =
> ImmutableSortedSet.copyOf(Arrays.asList(forcedLibs.split(":")));
> }
> }
>
> + @Inject(optional = true)
> + public void
> setExternalizeFeatureLibs(@Named("shindig.gadget-rewrite.externalize-feature-libs")Boolean
> externalizeFeatures) {
> + this.externalizeFeatures = externalizeFeatures;
> + }
> +
> public void rewrite(Gadget gadget, MutableContent mutableContent) throws
> RewritingException {
> // Don't touch sanitized gadgets.
> if (gadget.sanitizeOutput()) {
> @@ -215,40 +223,37 @@
> // TODO: If there isn't any js in the document, we can skip this.
> Unfortunately, that means
> // both script tags (easy to detect) and event handlers (much more
> complex).
> GadgetContext context = gadget.getContext();
> - String externParam = context.getParameter("libs");
>
> - // List of extern libraries we need
> - Set<String> extern;
> + // Set of extern libraries requested by the container
> + Set<String> externForcedLibs = defaultExternLibs;
>
> // gather the libraries we'll need to generate the extern libs
> - if (externParam == null || externParam.length() == 0) {
> - // Don't bother making a mutable copy if the list is empty
> - extern = (defaultExternLibs.isEmpty()) ? defaultExternLibs :
> - Sets.newTreeSet(defaultExternLibs);
> - } else {
> - extern = Sets.newTreeSet(Arrays.asList(externParam.split(":")));
> + String externParam = context.getParameter("libs");
> + if (StringUtils.isNotBlank(externParam)) {
> + externForcedLibs =
> Sets.newTreeSet(Arrays.asList(externParam.split(":")));
> }
> -
> - if (!extern.isEmpty()) {
> - String jsUrl = urlGenerator.getBundledJsUrl(extern, context);
> +
> + if (!externForcedLibs.isEmpty()) {
> + String jsUrl = urlGenerator.getBundledJsUrl(externForcedLibs,
> context);
> Element libsTag = headTag.getOwnerDocument().createElement("script");
> libsTag.setAttribute("src", jsUrl);
> headTag.appendChild(libsTag);
> }
> -
> +
> List<String> unsupported = Lists.newLinkedList();
> - List<FeatureResource> externResources =
> - featureRegistry.getFeatureResources(gadget.getContext(), extern,
> unsupported);
> +
> + List<FeatureResource> externForcedResources =
> + featureRegistry.getFeatureResources(context, externForcedLibs,
> unsupported);
> if (!unsupported.isEmpty()) {
> LOG.info("Unknown feature(s) in extern &libs=: " +
> unsupported.toString());
> unsupported.clear();
> }
> -
> +
> // Get all resources requested by the gadget's requires/optional
> features.
> Map<String, Feature> featureMap =
> gadget.getSpec().getModulePrefs().getFeatures();
> List<String> gadgetFeatureKeys =
> Lists.newArrayList(gadget.getDirectFeatureDeps());
> List<FeatureResource> gadgetResources =
> - featureRegistry.getFeatureResources(gadget.getContext(),
> gadgetFeatureKeys, unsupported);
> + featureRegistry.getFeatureResources(context, gadgetFeatureKeys,
> unsupported);
> if (!unsupported.isEmpty()) {
> List<String> requiredUnsupported = Lists.newLinkedList();
> for (String notThere : unsupported) {
> @@ -260,13 +265,33 @@
> if (!requiredUnsupported.isEmpty()) {
> throw new
> UnsupportedFeatureException(requiredUnsupported.toString());
> }
> + }
> +
> + // Inline or externalize the gadgetFeatureKeys
> + List<FeatureResource> inlineResources = Lists.newArrayList();
> + List<String> allRequested = Lists.newArrayList(gadgetFeatureKeys);
> +
> + if (externalizeFeatures) {
> + Set<String> externGadgetLibs =
> Sets.newTreeSet(featureRegistry.getFeatures(gadgetFeatureKeys));
> + externGadgetLibs.removeAll(externForcedLibs);
> +
> + if (!externGadgetLibs.isEmpty()) {
> + String jsUrl = urlGenerator.getBundledJsUrl(externGadgetLibs,
> context);
> + Element libsTag =
> headTag.getOwnerDocument().createElement("script");
> + libsTag.setAttribute("src", jsUrl);
> + headTag.appendChild(libsTag);
> + }
> + } else {
> + inlineResources.addAll(gadgetResources);
> }
> -
> +
> // Calculate inlineResources as all resources that are needed by the
> gadget to
> // render, minus all those included through externResources.
> // TODO: profile and if needed, optimize this a bit.
> - List<FeatureResource> inlineResources =
> Lists.newArrayList(gadgetResources);
> - inlineResources.removeAll(externResources);
> + if (!externForcedLibs.isEmpty()) {
> + allRequested.addAll(externForcedLibs);
> + inlineResources.removeAll(externForcedResources);
> + }
>
> // Precalculate the maximum length in order to avoid excessive garbage
> generation.
> int size = 0;
> @@ -280,8 +305,6 @@
> }
> }
>
> - List<String> allRequested = Lists.newArrayList(gadgetFeatureKeys);
> - allRequested.addAll(extern);
> String libraryConfig =
> getLibraryConfig(gadget,
> featureRegistry.getFeatures(allRequested));
>
> @@ -348,8 +371,7 @@
> }
>
> addHasFeatureConfig(gadget, config);
> - addOsapiSystemListMethodsConfig(gadget.getContext().getContainer(),
> config,
> - gadget.getContext().getHost());
> + addOsapiSystemListMethodsConfig(context.getContainer(), config,
> context.getHost());
> addSecurityTokenConfig(context, config);
> return "gadgets.config.init(" + JsonSerializer.serialize(config) +
> ");\n";
> }
>
>
>
Hey Artem,
You're quite right, this is indeed part of the spec and currently not
supported in PHP Shindig.
So far every developer who's worked with OpenSocial who's wanted to do GET's
has used the RESTful interface and not the RPC one, so this completely
dropped of my radar since no one complained about it.
For example this:
http://api.example.org/rpc?method=people.get&id=myself&userId=@me&groupI
d=@self<http://api.example.org/rpc?method=people.get&id=myself&userId=@me&groupId=@self>
can be simplified to
http://api.example.org/rest/people/@me/@self
Or if you want to specify a user id:
http://api.example.org/rest/people/User123/@self
Internally RPC and REST requests are represented in the same format and use
the same code path so as far as implementation and testing goes there's no
difference between the RPC and REST call.
In general we prefer the REST interface unless gains can be made through
batching, and RPC+GET removes that benefit since you can only specify a
single call, so it's not very high on my priority list either.
But, patches are welcome so if you have a strong case for why you require
this functionality we'd be happy to accept a patch to fix it up
-- Chris
On Sat, Dec 5, 2009 at 12:53 AM, Artem Russakovskii <artem@plaxo.com> wrote:
> Hi everyone,
>
>
>
> I believe this to be a Shindig bug but need some feedback validating my
> thoughts.
>
>
>
> According to the opensocial RPC spec
> http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/rpc-p
> rotocol, the following POST and GET RPC requests should be equivalent
> and allowed:
>
>
>
> POST:
>
> POST /rpc HTTP/1.1
> Host: api.example.org
> Authorization: <Auth token>
> Content-Type: application/json
> {
> "method" : "people.get",
>
> "id" : "myself"
> "params" : {
>
> "userId" : "@me",
> "groupId" : "@self"
>
> }
> }
>
>
>
> and
>
>
>
> GET:
>
> http://api.example.org/rpc?method=people.get&id=myself&userId=@me&groupI
> d=@self<http://api.example.org/rpc?method=people.get&id=myself&userId=@me&groupI%0Ad=@self>
>
>
>
> However, I believe Shindig's behavior (at least in PHP) is incorrect
> here.
>
>
>
> When a doGet() function gets called in JsonRpcServlet, it calls
> dispatch($request, $token), which expects parameters to be in
> $request->params.
>
>
>
> The problem is, if you compare the RPC spec url above with the JSON
> "equivalent", it looks like the url doesn't include a ¶ms GET
> variable - instead params like groupId, userId, etc are given as
> individual GET params. The shindig PHP code doesn't account for that and
> skips them altogether.
>
>
>
> Supporting the GET version of the spec would make debugging easier as
> it's a lot easier to send a GET request than a POST request (in addition
> to actually adhering to the spec, of course)
>
>
>
> Does anyone have any comments confirming this as a bug or otherwise?
>
>
>
> Thanks,
>
>
>
> Artem Russakovskii
>
> Plaxo Engineer
>
>
Didn't have time to deeply look at this. Only obvious thing I noted is that the diff lib should be test scope. http://codereview.appspot.com/157161/diff/3092/2084 File java/gadgets/pom.xml (right): http://codereview.appspot.com/157161/diff/3092/2084#newcode133 java/gadgets/pom.xml:133: <artifactId>diff_match_patch</artifactId> This should be <scope>test</scope> so we don't include this in the deployed artifacts. http://codereview.appspot.com/157161
Ha ha - good point! I thought about going out but its raining, so was dancing around on my own with mobile phone headpones on when phone pinged with notification of your little shindig. How is it progressing anyway? Have not looked at it in six months or more. On 5 Dec 2009 01:08, "John Hjelmstad" <fargo@google.com> wrote: I'm confused. Gate crashing typically means the party's worth going to! :) So as to prevent this topic from veering too off course, I proffer the following overview of the CL for anyone interested to review. I understand Paul and Louis are on board. All comments welcome. The changes are arrayed as follows: 1. Refactoring. Previously a large amount of generic (ie. should apply to any) HTML parser testing was stuck in the nekohtml-package tests. To the maximum extent possible, this has been pulled into parse-package classes: - AbstractParsingTestBase includes helper methods for any parsing- or serialization-based test. Pulled from AbstractParserAndSerializerTest - AbstractParserAndSerializer test contains several "common" parse/serialize tests no matter the concrete impl. - AbstractSocialMarkupHtmlParserTest pulls the social-markup test from Neko into a base class. - "Actual" tests are trivial subclasses of the abstract tests, providing a GadgetHtmlParser instance. - Tests converted to jUnit 4 as a side note. Subtleties: - Neko-based tests override a few base parse/serialize tests due to Neko oddities. All test files have been moved to base or nekohtml subdir to follow suit. 2. GadgetHtmlParser normalization implemented. - GadgetHtmlParser.normalizeFragment() removed - logic now inlined into parseDom(). + Rationale: IMO (open to discussion) the abstract parseDomImpl() API is unnecessary/does too much. Pretty much all gadget HTML is treated as tag soup and cleaned up. Having a base method whose contract is to give back unmodified tag soup thus seems right to me, with a single implementation of the normalization logic. - GadgetHtmlParser.parseDom() implements a large chunk of document normalization logic. It takes tag soup as input and returns a valid HTML document with a single top-level HTML element, in turn with two children: head and body. + Multiple <head> nodes consolidated together. Likewise body. + Elements above first <head> -> end up in head. + Elements above first <body> -> end up in body. + Elements after <body> -> end up in body unless inside a <head> node. + <style> nodes pulled to <head> in relative order - only HTML-compliant place for them, and no possibility that there will be conflicts (no displayable elements in <head>). - OpenSocial template parsing MAY be done as a post-processing pass on <script> nodes. Text found therein is treated as OS (X|HT)ML. Subtleties: - Lots. @see parseDom() impl especially. - NekoSimplifiedHtmlParser still impl's separate logic for parseDomImpl and parseFragmentImpl. I didn't dive into the difference and whether we could actually get rid of parseDomImpl in this round. 3. CajaHtmlParser implementation. - Depends on Caja r3889 (pom.xml updated to reflect this). - Unfortunately, parseDomImpl() does top-level <html> node synthesis to ensure document.getDocumentElement() returns it. This is for NekoSimplified/Caja dual compatibility w/ GadgetHtmlParser base logic. As noted, I'd prefer to move this synthesis code into GadgetHtmlParser.parseDom() if possible. - Pretty straightforward past that. Defers to Caja's parser for fragment processing. That's about it. Misc: setValijaMode(true) removed from CajaContentRewriter, since it's now default in the relevant Caja version. -j- On Fri, Dec 4, 2009 at 4:41 PM, Dan Shepherd <dan.x.shepherd@googlemail.com>wrote: > Indeed :) sorry for gate crashing! > > On 5 Dec 2009 00:35,...
I'm confused. Gate crashing typically means the party's worth going to! :)
So as to prevent this topic from veering too off course, I proffer the
following overview of the CL for anyone interested to review. I understand
Paul and Louis are on board. All comments welcome.
The changes are arrayed as follows:
1. Refactoring. Previously a large amount of generic (ie. should apply to
any) HTML parser testing was stuck in the nekohtml-package tests. To the
maximum extent possible, this has been pulled into parse-package classes:
- AbstractParsingTestBase includes helper methods for any parsing- or
serialization-based test. Pulled from AbstractParserAndSerializerTest
- AbstractParserAndSerializer test contains several "common"
parse/serialize tests no matter the concrete impl.
- AbstractSocialMarkupHtmlParserTest pulls the social-markup test from
Neko into a base class.
- "Actual" tests are trivial subclasses of the abstract tests, providing a
GadgetHtmlParser instance.
- Tests converted to jUnit 4 as a side note.
Subtleties:
- Neko-based tests override a few base parse/serialize tests due to Neko
oddities. All test files have been moved to base or nekohtml subdir to
follow suit.
2. GadgetHtmlParser normalization implemented.
- GadgetHtmlParser.normalizeFragment() removed - logic now inlined into
parseDom().
+ Rationale: IMO (open to discussion) the abstract parseDomImpl() API is
unnecessary/does too much. Pretty much all gadget HTML is treated as tag
soup and cleaned up. Having a base method whose contract is to give back
unmodified tag soup thus seems right to me, with a single implementation of
the normalization logic.
- GadgetHtmlParser.parseDom() implements a large chunk of document
normalization logic. It takes tag soup as input and returns a valid HTML
document with a single top-level HTML element, in turn with two children:
head and body.
+ Multiple <head> nodes consolidated together. Likewise body.
+ Elements above first <head> -> end up in head.
+ Elements above first <body> -> end up in body.
+ Elements after <body> -> end up in body unless inside a <head> node.
+ <style> nodes pulled to <head> in relative order - only HTML-compliant
place for them, and no possibility that there will be conflicts (no
displayable elements in <head>).
- OpenSocial template parsing MAY be done as a post-processing pass on
<script> nodes. Text found therein is treated as OS (X|HT)ML.
Subtleties:
- Lots. @see parseDom() impl especially.
- NekoSimplifiedHtmlParser still impl's separate logic for parseDomImpl
and parseFragmentImpl. I didn't dive into the difference and whether we
could actually get rid of parseDomImpl in this round.
3. CajaHtmlParser implementation.
- Depends on Caja r3889 (pom.xml updated to reflect this).
- Unfortunately, parseDomImpl() does top-level <html> node synthesis to
ensure document.getDocumentElement() returns it. This is for
NekoSimplified/Caja dual compatibility w/ GadgetHtmlParser base logic. As
noted, I'd prefer to move this synthesis code into
GadgetHtmlParser.parseDom() if possible.
- Pretty straightforward past that. Defers to Caja's parser for fragment
processing. That's about it.
Misc: setValijaMode(true) removed from CajaContentRewriter, since it's now
default in the relevant Caja version.
-j-
On Fri, Dec 4, 2009 at 4:41 PM, Dan Shepherd
<dan.x.shepherd@googlemail.com>wrote:
> Indeed :) sorry for gate crashing!
>
> On 5 Dec 2009 00:35, "John Hjelmstad" <fargo@google.com> wrote:
>
> At all the best Shindigs, people show up fashionably late.
>
> On Fri, Dec 4, 2009 at 4:32 PM, Dan Shepherd
> <dan.x.shepherd@googlemail.com>wrote:
>
> > Call this a shining? shouldn't you folks be out partying ;) > > On 5 Dec
> 2009 00:28, "Kevin Brown...
>
Hi everyone,
I believe this to be a Shindig bug but need some feedback validating my
thoughts.
According to the opensocial RPC spec
http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/rpc-protocol,
the following POST and GET RPC requests should be equivalent and allowed:
POST:
POST /rpc HTTP/1.1
Host: api.example.org
Authorization: <Auth token>
Content-Type: application/json
{
"method" : "people.get",
"id" : "myself"
"params" : {
"userId" : "@me",
"groupId" : "@self"
}
}
and
*GET:***
*
http://api.example.org/rpc?method=people.get&id=myself&userId=@me&groupId=@self
*
* *
However, I believe Shindig’s behavior (at least in PHP) is incorrect here.
When a doGet() function gets called in JsonRpcServlet, it calls
dispatch($request, $token), which expects parameters to be in
$request->params.
The problem is, if you compare the RPC spec url above with the JSON
“equivalent”, it looks like the url doesn’t include a ¶ms GET variable –
instead params like groupId, userId, etc are given as individual GET params.
The shindig PHP code doesn’t account for that and skips them altogether.
Supporting the GET version of the spec would make debugging easier as it’s a
lot easier to send a GET request than a POST request (in addition to
actually adhering to the spec, of course)
Does anyone have any comments confirming this as a bug or otherwise?
Thanks,
Artem Russakovskii
Plaxo Engineer
http://beerpla.net
http://twitter.com/ArtemR
Indeed :) sorry for gate crashing! On 5 Dec 2009 00:35, "John Hjelmstad" <fargo@google.com> wrote: At all the best Shindigs, people show up fashionably late. On Fri, Dec 4, 2009 at 4:32 PM, Dan Shepherd <dan.x.shepherd@googlemail.com>wrote: > Call this a shining? shouldn't you folks be out partying ;) > > On 5 Dec 2009 00:28, "Kevin Brown...
At all the best Shindigs, people show up fashionably late. On Fri, Dec 4, 2009 at 4:32 PM, Dan Shepherd <dan.x.shepherd@googlemail.com>wrote: > Call this a shining? shouldn't you folks be out partying ;) > > On 5 Dec 2009 00:28, "Kevin Brown" <etnu@google.com> wrote: > > I thought for sure someone else would have looked at it by now. I can look > at it over the weekend if you don't mind waiting until monday. > > On Fri, Dec 4, 2009 at 3:05 PM, <johnfargo@gmail.com> wrote: > Does anyone > have thoughts on this C... >
Call this a shining? shouldn't you folks be out partying ;) On 5 Dec 2009 00:28, "Kevin Brown" <etnu@google.com> wrote: I thought for sure someone else would have looked at it by now. I can look at it over the weekend if you don't mind waiting until monday. On Fri, Dec 4, 2009 at 3:05 PM, <johnfargo@gmail.com> wrote: > Does anyone have thoughts on this C...
I thought for sure someone else would have looked at it by now. I can look at it over the weekend if you don't mind waiting until monday. On Fri, Dec 4, 2009 at 3:05 PM, <johnfargo@gmail.com> wrote: > Does anyone have thoughts on this CL? It's been sitting for a week and a > half without comment, but is quite substantial and central to Shindig's > operation. All tests are retained, as is the default parser impl, but > changes nevertheless remain notable. > > > http://codereview.appspot.com/157161 >
Hi everyone,
I believe this to be a Shindig bug but need some feedback validating my
thoughts.
According to the opensocial RPC spec
http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/rpc-p
rotocol, the following POST and GET RPC requests should be equivalent
and allowed:
POST:
POST /rpc HTTP/1.1
Host: api.example.org
Authorization: <Auth token>
Content-Type: application/json
{
"method" : "people.get",
"id" : "myself"
"params" : {
"userId" : "@me",
"groupId" : "@self"
}
}
and
GET:
http://api.example.org/rpc?method=people.get&id=myself&userId=@me&groupI
d=@self
However, I believe Shindig's behavior (at least in PHP) is incorrect
here.
When a doGet() function gets called in JsonRpcServlet, it calls
dispatch($request, $token), which expects parameters to be in
$request->params.
The problem is, if you compare the RPC spec url above with the JSON
"equivalent", it looks like the url doesn't include a ¶ms GET
variable - instead params like groupId, userId, etc are given as
individual GET params. The shindig PHP code doesn't account for that and
skips them altogether.
Supporting the GET version of the spec would make debugging easier as
it's a lot easier to send a GET request than a POST request (in addition
to actually adhering to the spec, of course)
Does anyone have any comments confirming this as a bug or otherwise?
Thanks,
Artem Russakovskii
Plaxo Engineer
Does anyone have thoughts on this CL? It's been sitting for a week and a half without comment, but is quite substantial and central to Shindig's operation. All tests are retained, as is the default parser impl, but changes nevertheless remain notable. http://codereview.appspot.com/157161
Final patch set. Syncs and compiles cleanly against build@head. http://codereview.appspot.com/157161
I've experimented a bit more with locked domain by just setting up my
container to prepend a counter to the iframe url for each gadget -- so I end
up with iframe urls which look something like:
1.gadgets.mydomain.com/gadgets/ifr?url=...&st=...&rpctoken=...&...
2.gadgets.mydomain.com/gadgets/ifr?url=...&st=...&rpctoken=...&...
3.gadgets.mydomain.com/gadgets/ifr?url=...&st=...&rpctoken=...&...
...
(I realize that the urls should stay consistent across page renders for the
same gadget, but for testing purposes I just wanted to get the gadgets on
unique domains)
Everything seems to work just fine with this setup, and I do indeed see
additional sandboxing happening in the browser. I tested this by doing some
experimentation in FireFox using FireBug -- before implementing the locked
domain changes all of these statements in FireBug execute successfully:
cd($("remote_iframe_0").contentWindow); //change FireBug's context to the
window of one of the gadgets
console.log(document.location); //make sure the context is now what I
think it should be
var otherWindow = window.parent.frames["remote_iframe_1"]; //grab a
reference to the window of another gadget
console.log(otherWindow.location); //log its location to be sure I have a
hold of the iframe I think I do
console.log(otherWindow.document.getElementById('someElement').textContent);
//log out the content of an element in the other gadget
and as soon as I implement locked domain as described above, the last
statement fails with a security exception (as expected).
But I'm still left with a few questions...
1) Even with the gadgets rendering on their own domains, I can still get to
the location property of other gadgets on the page, which means I can parse
out things like the security tokens and rpc tokens -- doesn’t that mean one
gadget can still spoof another? How do other containers handle this?
2) I'm still trying to understand what all the locked domain code in Shindig
is for... I can see how some of it would be useful in my container (like
the logic in HashLockedDomainService that generates the iframe url based on
a hash of the gadget url) -- so is that why it’s there? To be use on the
container side? But then I also see methods in the LockedDomainService
interface that definitely seem Shindig specific like isSafeForOpenProxy and
gadgetCanRender, so I'm sure there must be more to it that I'm not
understanding... I've spent a bunch of time digging in the Shindig codebase
and searching through the mailing list looking for tidbits but haven’t made
much progress so far...
Any help or pointers would be greatly appreciated!
On Thu, Dec 3, 2009 at 9:55 AM, jss9920 <jss9920@gmail.com> wrote:
> I would like to start rendering my gadgets on unique locked domains but am
> getting a bit confused about where to start...
>
> Since the container generates the gadget iframe urls, it would seem that
> implementing locked domain would be a container side affair, but I see
> configuration options for locked domain support in the shindig container.js
> file and I also see associated Java classes that do a lot of locked domain
> work in the Shindig codebase (Java Shindig 1.0 release)...
>
> So is there actually work that needs to be done on both the container side
> and the Shindig side to enable locked domain gadgets?
>
> Any pointers on how to get started (even high level) would be helpful and
> much appreciated.
>
> Thanks!
>
Hey there.
I'm trying to implement requestSendMessage for partzua.
In the gadget I have this
<script type="text/javascript">
function sendNotification() {
var params = [];
params[opensocial.Message.Field.TITLE] = "title";
params[opensocial.Message.Field.TYPE] =
opensocial.Message.Type.NOTIFICATION;
var message = opensocial.newMessage("body",
params);
var recipient = opensocial.IdSpec.PersonId.OWNER;
opensocial.requestSendMessage(recipient, message,
callback);
};
function callback(data) {
if (data.hadError()) {
alert("There was a problem:" + data.getErrorCode());
} else {
alert("Ok");
}
};
</script>
and in my container.js I've added
init: function() {
...
gadgets.rpc.register('requestSendMessage',
this.requestSendMessage);
},
and now I need a little help to understand what should I do next, in
my method
requestSendMessage: function() {
}
and now I need a little help to understand what should I do next, in
my method
requestSendMessage: function() {
}
I'm debugging the entire code to have a notion of shindig -
partuza interaction flow,
and that is what I found..
gadgets.json.stringify function (..rps/wpm.transport.js) changes the
entire rpc object structure... I mean that some fields of that object
(i.e the array containing
title, body and message type) are getting changed ...hence in my
container.js (partuza's) in requestSendMessage function(that I should
implement) I can get only the recipient, but no message to proceed.
something is wrong with my code:( or I'm doing so..
Any help is appreciated.
Updated: Caja piece is committed, pom.xml update reflects same. JDK 6->5 tweaks needed still. http://codereview.appspot.com/157161
Reviewers: shindig.remailer_gmail.com,
Description:
setupReceiver('..') initializes gadget-to-container communication, but
should be called in init() after gadgets.rpc as an object is set up.
Please review this at http://codereview.appspot.com/165052
Affected files:
features/src/main/javascript/features/rpc/rpc.js
Index: features/src/main/javascript/features/rpc/rpc.js
===================================================================
--- features/src/main/javascript/features/rpc/rpc.js (revision 887018)
+++ features/src/main/javascript/features/rpc/rpc.js (working copy)
@@ -530,11 +530,6 @@
}
}
- // gadgets.config might not be available, such as when serving container
js.
- if (isChild) {
- setupReceiver('..');
- }
-
return /** @scope gadgets.rpc */ {
/**
* Registers an RPC service.
@@ -817,6 +812,9 @@
if (transport.init(process, transportReady) === false) {
transport = fallbackTransport;
}
+ if (isChild) {
+ setupReceiver('..');
+ }
},
/** Returns the window keyed by the ID. null/".." for parent, else
child */
On 2009/12/04 00:36:09, johnfargo wrote: > @Paul, sgtm. Style update. great, ship it! http://codereview.appspot.com/166046
Good find, thanks -- updated w/ comment and put a watch on it.
On Thu, Dec 3, 2009 at 4:35 PM, Paul Lindner <lindner@inuus.com> wrote:
> https://issues.apache.org/jira/browse/SHINDIG-1234 ?
>
>
> On Thu, Dec 3, 2009 at 12:12 PM, John Hjelmstad <fargo@google.com> wrote:
>
> > Possible, though on a search I don't see any obvious candidates offhand?
> >
> > On Thu, Dec 3, 2009 at 12:09 PM, Paul Lindner <lindner@inuus.com> wrote:
> >
> > > Isn't this related to a JIRA issue recently filed?
> > >
> > >
> > > On Thu, Dec 3, 2009 at 11:50 AM, <johnh@apache.org> wrote:
> > >
> > > > Author: johnh
> > > > Date: Thu Dec 3 19:50:22 2009
> > > > New Revision: 886897
> > > >
> > > > URL: http://svn.apache.org/viewvc?rev=886897&view=rev
> > > > Log:
> > > > Don't invert the order of script blocks added to body.
> > > >
> > > >
> > > > Modified:
> > > >
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> > > >
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> > > >
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> > > >
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> > > >
> > > > Modified:
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> > > > URL:
> > > >
> > >
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java?rev=886897&r1=886896&r2=886897&view=diff
> > > >
> > > >
> > >
> >
> ==============================================================================
> > > > ---
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> > > > (original)
> > > > +++
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> > > > Thu Dec 3 19:50:22 2009
> > > > @@ -210,6 +210,7 @@
> > > > Node headScript = headScripts.pop();
> > > > head.removeChild(headScript);
> > > > body.insertBefore(headScript, bodyFirst);
> > > > + bodyFirst = headScript;
> > > > }
> > > > }
> > > >
> > > >
> > > > Modified:
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> > > > URL:
> > > >
> > >
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java?rev=886897&r1=886896&r2=886897&view=diff
> > > >
> > > >
> > >
> >
> ==============================================================================
> > > > ---
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> > > > (original)
> > > > +++
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> > > > Thu Dec 3 19:50:22 2009
> > > > @@ -44,6 +44,6 @@
> > > > throws Exception {
> > > > Document document = parser.parseDom(content);
> > > > expected = StringUtils.replace(expected, EOL, "\n");
> > > > - assertEquals(expected, HtmlSerialization.serialize(document));
> > > > + assertEquals(expected.trim(),
> > > > HtmlSerialization.serialize(document).trim());
> > > > }
> > > > }
> > > >
> > > > Modified:
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> > > > URL:
> > > >
> > >
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html?rev=886897&r1=886896&r2=886897&view=diff
> > > >
> > > >
> > >
> >
> ==============================================================================
> > > > ---
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> > > > (original)
> > > > +++
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> > > > Thu Dec 3 19:50:22 2009
> > > > @@ -3,4 +3,5 @@
> > > >
> > > > <link rel="linkrel">
> > > >
> > > >
> > >
> >
> -</head><body><script>foo3();</script><script>foo2();</script><script>foo1();</script><div
> > > > id="mydiv">mycontent</div></body></html>
> > > > \ No newline at end of file
> > > >
> > >
> >
> +</head><body><script>foo1();</script><script>foo2();</script><script>foo3();</script><div
> > > > id="mydiv">mycontent</div>
> > > > +</body></html>
> > > >
> > > > Modified:
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> > > > URL:
> > > >
> > >
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html?rev=886897&r1=886896&r2=886897&view=diff
> > > >
> > > >
> > >
> >
> ==============================================================================
> > > > ---
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> > > > (original)
> > > > +++
> > > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> > > > Thu Dec 3 19:50:22 2009
> > > > @@ -3,4 +3,4 @@
> > > > <script>foo2();</script>
> > > > <link rel="linkrel"/>
> > > > <script>foo3();</script>
> > > > -<div id="mydiv">mycontent</div>
> > > > \ No newline at end of file
> > > > +<div id="mydiv">mycontent</div>
> > > >
> > > >
> > > >
> > >
> >
>
@Paul, sgtm. Style update. http://codereview.appspot.com/166046
https://issues.apache.org/jira/browse/SHINDIG-1234 ?
On Thu, Dec 3, 2009 at 12:12 PM, John Hjelmstad <fargo@google.com> wrote:
> Possible, though on a search I don't see any obvious candidates offhand?
>
> On Thu, Dec 3, 2009 at 12:09 PM, Paul Lindner <lindner@inuus.com> wrote:
>
> > Isn't this related to a JIRA issue recently filed?
> >
> >
> > On Thu, Dec 3, 2009 at 11:50 AM, <johnh@apache.org> wrote:
> >
> > > Author: johnh
> > > Date: Thu Dec 3 19:50:22 2009
> > > New Revision: 886897
> > >
> > > URL: http://svn.apache.org/viewvc?rev=886897&view=rev
> > > Log:
> > > Don't invert the order of script blocks added to body.
> > >
> > >
> > > Modified:
> > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> > >
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> > >
> > > Modified:
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java?rev=886897&r1=886896&r2=886897&view=diff
> > >
> > >
> >
> ==============================================================================
> > > ---
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> > > (original)
> > > +++
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> > > Thu Dec 3 19:50:22 2009
> > > @@ -210,6 +210,7 @@
> > > Node headScript = headScripts.pop();
> > > head.removeChild(headScript);
> > > body.insertBefore(headScript, bodyFirst);
> > > + bodyFirst = headScript;
> > > }
> > > }
> > >
> > >
> > > Modified:
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java?rev=886897&r1=886896&r2=886897&view=diff
> > >
> > >
> >
> ==============================================================================
> > > ---
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> > > (original)
> > > +++
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> > > Thu Dec 3 19:50:22 2009
> > > @@ -44,6 +44,6 @@
> > > throws Exception {
> > > Document document = parser.parseDom(content);
> > > expected = StringUtils.replace(expected, EOL, "\n");
> > > - assertEquals(expected, HtmlSerialization.serialize(document));
> > > + assertEquals(expected.trim(),
> > > HtmlSerialization.serialize(document).trim());
> > > }
> > > }
> > >
> > > Modified:
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html?rev=886897&r1=886896&r2=886897&view=diff
> > >
> > >
> >
> ==============================================================================
> > > ---
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> > > (original)
> > > +++
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> > > Thu Dec 3 19:50:22 2009
> > > @@ -3,4 +3,5 @@
> > >
> > > <link rel="linkrel">
> > >
> > >
> >
> -</head><body><script>foo3();</script><script>foo2();</script><script>foo1();</script><div
> > > id="mydiv">mycontent</div></body></html>
> > > \ No newline at end of file
> > >
> >
> +</head><body><script>foo1();</script><script>foo2();</script><script>foo3();</script><div
> > > id="mydiv">mycontent</div>
> > > +</body></html>
> > >
> > > Modified:
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html?rev=886897&r1=886896&r2=886897&view=diff
> > >
> > >
> >
> ==============================================================================
> > > ---
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> > > (original)
> > > +++
> > >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> > > Thu Dec 3 19:50:22 2009
> > > @@ -3,4 +3,4 @@
> > > <script>foo2();</script>
> > > <link rel="linkrel"/>
> > > <script>foo3();</script>
> > > -<div id="mydiv">mycontent</div>
> > > \ No newline at end of file
> > > +<div id="mydiv">mycontent</div>
> > >
> > >
> > >
> >
>
lgtm other than the style issue. http://codereview.appspot.com/166046/diff/7/1007 File features/src/main/javascript/features/rpc/rpc.js (left): http://codereview.appspot.com/166046/diff/7/1007#oldcode297 features/src/main/javascript/features/rpc/rpc.js:297: Since this is an internal routine we might want to make this _getTargetWin http://codereview.appspot.com/166046
Old patch accidentally uploaded. Fixed (correctly this time). http://codereview.appspot.com/166046
Old patch accidentally uploaded. fixed. http://codereview.appspot.com/166046
Reviewers: shindig.remailer_gmail.com,
Description:
Turns out IE8 treats this as an Array access rather than Object/Map:
window.frames["1234"]
This caused gadgets.rpc to break when the frame name consists only of
isDigit characters.
I propose this patch as a way of centralizing the targetWindow retrieval
mechanism for rpc. It also tries falling back to
document.getElementById(...) if a window.frames find doesn't work.
Comments welcome.
Please review this at http://codereview.appspot.com/166046
Affected files:
features/src/main/javascript/features/rpc/rmr.transport.js
features/src/main/javascript/features/rpc/rpc.js
features/src/main/javascript/features/rpc/wpm.transport.js
Index: features/src/main/javascript/features/rpc/rpc.js
===================================================================
--- features/src/main/javascript/features/rpc/rpc.js (revision 886897)
+++ features/src/main/javascript/features/rpc/rpc.js (working copy)
@@ -295,6 +295,30 @@
return protocol + "://" + host + portStr;
}
+ function getTargetWindow(id) {
+ if (typeof id === "undefined" ||
+ id === "..") {
+ return window.parent;
+ }
+
+ // Cast to a String to avoid an index lookup.
+ id = String(id);
+
+ // Try window.frames first
+ var target = window.frames[id];
+ if (target) {
+ return target;
+ }
+
+ // Fall back to getElementById()
+ target = document.getElementById(id);
+ if (target && target.contentWindow) {
+ return target.contentWindow;
+ }
+
+ return null;
+ }
+
// Pick the most efficient RPC relay mechanism.
var transport = getTransport();
@@ -369,12 +393,7 @@
return false;
}
- var targetEl = null;
- if (target === '..') {
- targetEl = window.parent;
- } else {
- targetEl = window.frames[target];
- }
+ var targetEl = getTargetWin(target);
try {
// If this succeeds, then same-domain policy applied
sameDomain[target] = targetEl.gadgets.rpc.receiveSameDomain;
@@ -800,6 +819,9 @@
}
},
+ /** Returns the window keyed by the ID. null/".." for parent, else
child */
+ getTargetWindow: getTargetWindow,
+
/** Exported constant, for use by transports only. */
ACK: ACK,
Index: features/src/main/javascript/features/rpc/rmr.transport.js
===================================================================
--- features/src/main/javascript/features/rpc/rmr.transport.js (revision
886897)
+++ features/src/main/javascript/features/rpc/rmr.transport.js (working
copy)
@@ -195,12 +195,13 @@
rmr_channels[frameId].searchCounter++;
try {
+ var targetWin = gadgets.rpc.getTargetWin(frameId);
if (frameId === '..') {
// We are a gadget.
- channelWindow = window.parent.frames['rmrtransport-' +
gadgets.rpc.RPC_ID];
+ channelWindow = targetWin.frames['rmrtransport-' +
gadgets.rpc.RPC_ID];
} else {
// We are a container.
- channelWindow = window.frames[frameId].frames['rmrtransport-..'];
+ channelWindow = targetWin.frames['rmrtransport-..'];
}
} catch (e) {
// Just in case; may happen when relay is set to about:blank or
unset.
Index: features/src/main/javascript/features/rpc/wpm.transport.js
===================================================================
--- features/src/main/javascript/features/rpc/wpm.transport.js (revision
886897)
+++ features/src/main/javascript/features/rpc/wpm.transport.js (working
copy)
@@ -81,7 +81,7 @@
},
call: function(targetId, from, rpc) {
- var targetWin = targetId === '..' ? window.parent :
window.frames[targetId];
+ var targetWin = gadgets.rpc.getTargetWin(targetId);
// targetOrigin = canonicalized relay URL
var origRelay = gadgets.rpc.getRelayUrl(targetId) ||
gadgets.util.getUrlParameters()["parent"];
Looks great Ziv - patch committed, thanks! http://codereview.appspot.com/164080
Possible, though on a search I don't see any obvious candidates offhand?
On Thu, Dec 3, 2009 at 12:09 PM, Paul Lindner <lindner@inuus.com> wrote:
> Isn't this related to a JIRA issue recently filed?
>
>
> On Thu, Dec 3, 2009 at 11:50 AM, <johnh@apache.org> wrote:
>
> > Author: johnh
> > Date: Thu Dec 3 19:50:22 2009
> > New Revision: 886897
> >
> > URL: http://svn.apache.org/viewvc?rev=886897&view=rev
> > Log:
> > Don't invert the order of script blocks added to body.
> >
> >
> > Modified:
> >
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> >
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> >
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> >
> > Modified:
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> > URL:
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java?rev=886897&r1=886896&r2=886897&view=diff
> >
> >
> ==============================================================================
> > ---
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> > (original)
> > +++
> >
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> > Thu Dec 3 19:50:22 2009
> > @@ -210,6 +210,7 @@
> > Node headScript = headScripts.pop();
> > head.removeChild(headScript);
> > body.insertBefore(headScript, bodyFirst);
> > + bodyFirst = headScript;
> > }
> > }
> >
> >
> > Modified:
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> > URL:
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java?rev=886897&r1=886896&r2=886897&view=diff
> >
> >
> ==============================================================================
> > ---
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> > (original)
> > +++
> >
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> > Thu Dec 3 19:50:22 2009
> > @@ -44,6 +44,6 @@
> > throws Exception {
> > Document document = parser.parseDom(content);
> > expected = StringUtils.replace(expected, EOL, "\n");
> > - assertEquals(expected, HtmlSerialization.serialize(document));
> > + assertEquals(expected.trim(),
> > HtmlSerialization.serialize(document).trim());
> > }
> > }
> >
> > Modified:
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> > URL:
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html?rev=886897&r1=886896&r2=886897&view=diff
> >
> >
> ==============================================================================
> > ---
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> > (original)
> > +++
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> > Thu Dec 3 19:50:22 2009
> > @@ -3,4 +3,5 @@
> >
> > <link rel="linkrel">
> >
> >
> -</head><body><script>foo3();</script><script>foo2();</script><script>foo1();</script><div
> > id="mydiv">mycontent</div></body></html>
> > \ No newline at end of file
> >
> +</head><body><script>foo1();</script><script>foo2();</script><script>foo3();</script><div
> > id="mydiv">mycontent</div>
> > +</body></html>
> >
> > Modified:
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> > URL:
> >
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html?rev=886897&r1=886896&r2=886897&view=diff
> >
> >
> ==============================================================================
> > ---
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> > (original)
> > +++
> >
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> > Thu Dec 3 19:50:22 2009
> > @@ -3,4 +3,4 @@
> > <script>foo2();</script>
> > <link rel="linkrel"/>
> > <script>foo3();</script>
> > -<div id="mydiv">mycontent</div>
> > \ No newline at end of file
> > +<div id="mydiv">mycontent</div>
> >
> >
> >
>
Isn't this related to a JIRA issue recently filed?
On Thu, Dec 3, 2009 at 11:50 AM, <johnh@apache.org> wrote:
> Author: johnh
> Date: Thu Dec 3 19:50:22 2009
> New Revision: 886897
>
> URL: http://svn.apache.org/viewvc?rev=886897&view=rev
> Log:
> Don't invert the order of script blocks added to body.
>
>
> Modified:
>
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
>
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
>
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
>
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
>
> Modified:
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> URL:
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java?rev=886897&r1=886896&r2=886897&view=diff
>
> ==============================================================================
> ---
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> (original)
> +++
> incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoSimplifiedHtmlParser.java
> Thu Dec 3 19:50:22 2009
> @@ -210,6 +210,7 @@
> Node headScript = headScripts.pop();
> head.removeChild(headScript);
> body.insertBefore(headScript, bodyFirst);
> + bodyFirst = headScript;
> }
> }
>
>
> Modified:
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> URL:
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java?rev=886897&r1=886896&r2=886897&view=diff
>
> ==============================================================================
> ---
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> (original)
> +++
> incubator/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/AbstractParserAndSerializerTest.java
> Thu Dec 3 19:50:22 2009
> @@ -44,6 +44,6 @@
> throws Exception {
> Document document = parser.parseDom(content);
> expected = StringUtils.replace(expected, EOL, "\n");
> - assertEquals(expected, HtmlSerialization.serialize(document));
> + assertEquals(expected.trim(),
> HtmlSerialization.serialize(document).trim());
> }
> }
>
> Modified:
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> URL:
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html?rev=886897&r1=886896&r2=886897&view=diff
>
> ==============================================================================
> ---
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> (original)
> +++
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript-expected.html
> Thu Dec 3 19:50:22 2009
> @@ -3,4 +3,5 @@
>
> <link rel="linkrel">
>
> -</head><body><script>foo3();</script><script>foo2();</script><script>foo1();</script><div
> id="mydiv">mycontent</div></body></html>
> \ No newline at end of file
> +</head><body><script>foo1();</script><script>foo2();</script><script>foo3();</script><div
> id="mydiv">mycontent</div>
> +</body></html>
>
> Modified:
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> URL:
> http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html?rev=886897&r1=886896&r2=886897&view=diff
>
> ==============================================================================
> ---
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> (original)
> +++
> incubator/shindig/trunk/java/gadgets/src/test/resources/org/apache/shindig/gadgets/parse/nekohtml/test-leadingscript.html
> Thu Dec 3 19:50:22 2009
> @@ -3,4 +3,4 @@
> <script>foo2();</script>
> <link rel="linkrel"/>
> <script>foo3();</script>
> -<div id="mydiv">mycontent</div>
> \ No newline at end of file
> +<div id="mydiv">mycontent</div>
>
>
>
I would like to start rendering my gadgets on unique locked domains but am getting a bit confused about where to start... Since the container generates the gadget iframe urls, it would seem that implementing locked domain would be a container side affair, but I see configuration options for locked domain support in the shindig container.js file and I also see associated Java classes that do a lot of locked domain work in the Shindig codebase (Java Shindig 1.0 release)... So is there actually work that needs to be done on both the container side and the Shindig side to enable locked domain gadgets? Any pointers on how to get started (even high level) would be helpful and much appreciated. Thanks!
Just browsing the feature files, and noticed that there is container side content for: core.io and core.util, yet I don't see any obvious calls being made to these. Does anyone know why they are present? Perhaps we could remove them? Thanks, Jon
The concept of having a framework (e.g. OpenSocial Gadgets) that allows
developers to embed a custom application into a page, whether HTML
gadget or URL "thing" is very valuable. The URL "thing" should interact
with the page the way HTML gadgets do, but the style of application
development is very different.
I'm open to Randy's comments on what to call them, or how to position
them for the community. Somewhere I remember Google's initial position
on URL gadgets as a way to quickly port an existing application into the
gadget framework.
Just to correct a few things from the specifics of Java API:
- RPC should be able to work both ways, ifpc with RpcRelay file is one
pain, but ifpc is fading away. Not to mention that 2-way rpc may be
little used till pubsub comes back in its full glory and by that time
ifpc will not be an issue.
- up_xxx should work fine. But unlike HTML gadgets using Prefs(), URL
gadgets simply get the query parameters server side.
- view parameters (from requestNavigateTo()), well that's not part of
the OpenSocial specification - but a spec update is all that's needed.
- Yes, makeRequest, templating, pipelining, preloading, etc... All don't
work, but that's the "very different" style of development that URL
gadget authors face.
- Remember all OpenSocial data is available via REST and RPC calls.
- Feature parameters - not sure where Shindig uses that?
- Container config - another issue - that will be handled by the new
RenderContext==URLGADGET, and the JsServlet will generate the proper
code. This is the equivalent of the RenderingGadgetRewriter inject
methods. This is one of the areas where there are issues, and my
thoughts are that we inject only what is invariant wrt user parameters.
-----Original Message-----
From: Randy Hudson [mailto:hudsonr@us.ibm.com]
Sent: Wednesday, December 02, 2009 9:02 AM
To: shindig-dev@incubator.apache.org
Subject: RE: Next step towards URL gadgets - design proposal
Are URL "gadgets" even gadgets? They seem to have the following
gaps/limitations:
- Even though they are given a URL from which to fetch javascript, most
of the javascript won't function
- RPC only works in one direction (?)
- makeRequest, proxying, appdata, etc. are all broken
- Templating and markup aren't supported
- Data pipelining isn't supported
- Preloading resources isn't supported
- Providing userprefs or messages as URL params doesn't really work
- View parameters, Feature parameters aren't available
I find it confusing that these "embedded pages" are called gadgets, when
often they are little more than a bookmark to some external site (like
twitter), typically having little interaction with the site in which
they appear.
I like Jon's suggestion of scoping URL gadgets to some very small API
(perhaps just being able to update the "chrome", requesting to be
maximized, etc.). Maybe it would help to start calling these things
something other than Gadgets? Otherwise, there's this subliminal force
telling us to provide two different ways of doing everything, often when
one way is enough (e.g. Jon's reference to message bundles).
--Randy Hudson
From:
"Weygandt, Jon" <jweygandt@ebay.com>
To:
<shindig-dev@incubator.apache.org>
Date:
12/01/2009 11:31 AM
Subject:
RE: Next step towards URL gadgets - design proposal
Just so that it is known, more on the design: I'm taking liberty in
defining "URL gadget JS API" based on:
*) Shindig does not support anything today.
*) Very few actual server implementations for URL gadgets exist
*) Our experience with URL gadgets. Our implementation has quite a few
URL gadgets, but the implementation is propriety
*) You cannot support cross domain XMLHttpRequests - no makeRequest
etc...
Just to go a bit further...
Just about every URL gadget author will have a multi-page URL gadget.
That is one which the location URL changes over time. That's just the
typical pattern for these type of applications. We must make the
interface work for them, and be relatively easy for them to implement.
I believe that full API support using libs, would require either:
*) A really long lib URL
*) Maintenance of session state on the server
*) A complex calling procedure
None of the above are really good.
But if we narrow down the scope of the API to simply what cannot be
replaced by typical URL server side code, it then becomes easier.
For an example, think about how one would do message bundles
Prefs.getMsg? (These need user prefs for hangman substitution) Then
think, does a URL gadget developer even need this? (They don't, I18N is
done differently for URL apps)
Jon
-----Original Message-----
From: Weygandt, Jon [mailto:jweygandt@ebay.com]
Sent: Tuesday, December 01, 2009 8:14 AM
To: shindig-dev@incubator.apache.org
Subject: RE: Next step towards URL gadgets - design proposal
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.Shtein@Metavante.com [mailto:Ilya.Shtein@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" <jweygandt@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.Shtein@Metavante.com [mailto:Ilya.Shtein@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" <jweygandt@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.
---------------------------------------------------------------------
Are URL "gadgets" even gadgets? They seem to have the following
gaps/limitations:
- Even though they are given a URL from which to fetch javascript, most
of the javascript won't function
- RPC only works in one direction (?)
- makeRequest, proxying, appdata, etc. are all broken
- Templating and markup aren't supported
- Data pipelining isn't supported
- Preloading resources isn't supported
- Providing userprefs or messages as URL params doesn't really work
- View parameters, Feature parameters aren't available
I find it confusing that these "embedded pages" are called gadgets, when
often they are little more than a bookmark to some external site (like
twitter), typically having little interaction with the site in which they
appear.
I like Jon's suggestion of scoping URL gadgets to some very small API
(perhaps just being able to update the "chrome", requesting to be
maximized, etc.). Maybe it would help to start calling these things
something other than Gadgets? Otherwise, there's this subliminal force
telling us to provide two different ways of doing everything, often when
one way is enough (e.g. Jon's reference to message bundles).
--Randy Hudson
From:
"Weygandt, Jon" <jweygandt@ebay.com>
To:
<shindig-dev@incubator.apache.org>
Date:
12/01/2009 11:31 AM
Subject:
RE: Next step towards URL gadgets - design proposal
Just so that it is known, more on the design: I'm taking liberty in
defining "URL gadget JS API" based on:
*) Shindig does not support anything today.
*) Very few actual server implementations for URL gadgets exist
*) Our experience with URL gadgets. Our implementation has quite a few
URL gadgets, but the implementation is propriety
*) You cannot support cross domain XMLHttpRequests - no makeRequest
etc...
Just to go a bit further...
Just about every URL gadget author will have a multi-page URL gadget.
That is one which the location URL changes over time. That's just the
typical pattern for these type of applications. We must make the
interface work for them, and be relatively easy for them to implement.
I believe that full API support using libs, would require either:
*) A really long lib URL
*) Maintenance of session state on the server
*) A complex calling procedure
None of the above are really good.
But if we narrow down the scope of the API to simply what cannot be
replaced by typical URL server side code, it then becomes easier.
For an example, think about how one would do message bundles
Prefs.getMsg? (These need user prefs for hangman substitution)
Then think, does a URL gadget developer even need this? (They don't,
I18N is done differently for URL apps)
Jon
-----Original Message-----
From: Weygandt, Jon [mailto:jweygandt@ebay.com]
Sent: Tuesday, December 01, 2009 8:14 AM
To: shindig-dev@incubator.apache.org
Subject: RE: Next step towards URL gadgets - design proposal
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.Shtein@Metavante.com [mailto:Ilya.Shtein@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" <jweygandt@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.Shtein@Metavante.com [mailto:Ilya.Shtein@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" <jweygandt@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.
---------------------------------------------------------------------
Hmm this is quickly running outside of my area of expertise, I'm not
terribly familiar with the current internals of the gadget<>container rpc
structure.
I think it would be best if you took this question to the shindig-dev list,
where our resident experts on this topic can be found, see
http://incubator.apache.org/shindig/community/getting-help.html for details
on how to sign up
-- Chris
On Wed, Dec 2, 2009 at 3:55 PM, Mel Morrow <mel.morow@gmail.com> wrote:
> Thanks Chris for your patience:)
>
> Actually I'm diving into the code...I've found something that leaves a
> mess..
>
> I'm debugging the entire code to have a notion of shindig - partuza
> interaction flow, and
> that is what I found..
>
> gadgets.json.stringify function (..rps/wpm.transport.js) changes the
> entire rpc object structure... I mean that some fields of that object
> (i.e the array containing
> title, body and message type) are getting changed ...hence in my
> container.js (partuza's) in requestSendMessage function(that I should
> implement) I can get only the recipient, but no message to proceed.
>
> something is wrong with my code:( or I'm doing so..
>
>
> On Dec 2, 3:13 pm, Chris Chabot <chab...@google.com> wrote:
> > On Wed, Dec 2, 2009 at 9:05 AM, Mel Morrow <mel.mo...@gmail.com> wrote:
> >
> > > requestSendMessage: function() {
> >
> > > }
> >
> > > this is what I need..
> >
> > Well, there you send stuff! :-)
> >
> > Really the implementation details are completely up to you, if you wanted
> to
> > add this functionality to partuza I would suggest adding a new controller
> > (partuza/Application/Controllers) that can receive the message post, and
> > just do a simple Ajax post to that url (suggestion: do include the
> security
> > token so you can validate it's not a abuse of the functionality, and can
> > retrieve or compare the app id and viewer id).
> >
> > I know that probably doesn't sound like a useful suggestion, but there's
> > just no replacing actually diving into the code and figuring it out to
> see
> > how it works
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Implementing OpenSocial Containers" group.
> To post to this group, send email to opensocial-container@googlegroups.com
> .
> To unsubscribe from this group, send email to
> opensocial-container+unsubscribe@googlegroups.com<opensocial-container%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/opensocial-container?hl=en.
>
>
>
Hafiz,
I had the same issue that you are seeing and it had to do with the NIX transport setup. When
a gadget is rendered the first time, the NIX transport sets up both the container and gadget
hook at the same time. Since I was not re-rendering the page when switching to canvas view,
when the gadget was told to render in canvas view it was failing to establish the connection
with the NIX transport on the container side since the container's side of the NIX transport
setup was already running.
I put a hack in place to force the rpc.js to setup the frame when I called setAuthToken after
switching to canvas view. I am still trying to work out a better solution so that I can submit
a bug.
I am quite a bit behind at this point, since I haven't downloaded the latest BETA for Shindig,
but the problem for me exists in the setupFrame function in the rpc.js file for the rpc feature.
If you look, the setup array on the container shows that the frame has already been setup
when switching to canvas view so it just returns. In the case of the NIX transport with IE7,
switching to canvas view kills the frames reference to the VBScript for the NIX transport
and its link to the container.
Hopefully this points you in the right direction. I need to download the latest code for
Shindig so I can put together a sensible fix for this issue.
Steve T.
-----Original Message-----
From: Hafiz A Haq [mailto:hafizahaq@gmail.com]
Sent: Wednesday, December 02, 2009 12:42 AM
To: shindig-dev@incubator.apache.org
Subject: Re: Issue with different secure domains for container and shindig
Thank you John for the helping hand.
I just noticed one more strange behavior, probably is already discussed in the thread - http://markmail.org/thread/zorpp3exisyei76w
When i maximize the gadget, i change the view to canvas, and the rpcs fail in ie7. I could
fix the issue by rerendering the gadget with a new moduleId.
Any recommendation on the proper fix for this one?
Thanks and Regards,
Hafiz
2009/12/1 John Hjelmstad <fargo@google.com>
> Hi Hafiz:
>
> Sounds like this has something to do with the way that numeric values
> are coerced to and from String values in JS. Forcing the value to be a
> String (w/ a non-numeric char) is a fine solution for the moment. A
> colleague recently saw this behavior as well. I'll take a look when I get some time.
>
> Let me know if you run into any other troubles-
>
> --j
>
> On Mon, Nov 30, 2009 at 11:32 PM, Hafiz A Haq <hafizahaq@gmail.com> wrote:
>
> > Seems appending a random character to the random number has fixed
> > the issue, atleast in my dev environment.
> >
> > I will update you once the build makes it to production. Waiting
> > with my fingers crossed.
> >
> > Thanks and Regards,
> > Hafiz
> >
> > 2009/11/25 John Hjelmstad <fargo@google.com>
> >
> > > Throwing a few ideas out there:
> > >
> > > 1. Rather than your rpctoken being (interpreted as) a number,
> > > ensure
> it's
> > a
> > > string by prepending "A" or something to it.
> > > 2. Any chance VBScript is disabled for you?
> > >
> > > -j-
> > >
> > > On Sun, Nov 22, 2009 at 10:30 PM, Hafiz A Haq
> > > <hafizahaq@gmail.com>
> > wrote:
> > >
> > > > 2009/11/21 John Hjelmstad <fargo@google.com>
> > > >
> > > > > 1. Ah, version 1.1-beta2. I can't recall whether that version
> > > > > has
> the
> > > new
> > > > > NIX protocol in it or not. Does your /gadgets/js/rpc.js?c=1
> > > > > file
> > > contain
> > > > > symbols named gadgets.rpctx.nix*?
> > > > >
> > > > >
> > > > I tried 1.1beta2 and 1.1beta4 , i could find something like
> > > >
> > > > gadgets.rpctx.nix=function(){var C="GRPC____NIXVBS_wrapper";
> > > >
> > > > 2. Do you have a special container config for
> > > > container=smx-container
> > > that
> > > > > overrides any values for "gadgets.features":{"rpc"...?
> > > > >
> > > > >
> > > > "rpc" : {
> > > > // Path to the relay file. Automatically appended to the parent
> > > > /// parameter if it passes input validation and is not null.
> > > > // This should never be on the same host in a production
> > environment!
> > > > // Only use this for TESTING!
> > > > "parentRelayUrl" : "/app/core/main/rpc_relay.html",
> > > >
> > > > // If true, this will use the legacy ifpc wire format when
> > > > making
> > rpc
> > > > // requests.
> > > > "useLegacyProtocol" : false
> > > > }
> > > >
> > > >
> > > > Anything amiss here?
> > > >
> > > > Thanks and Regards,
> > > > Hafiz
> > > >
> > > >
> > > > On Fri, Nov 20, 2009 at 4:51 AM, Hafiz A Haq
> > > > <hafizahaq@gmail.com>
> > > wrote:
> > > > >
> > > > > > Thanks a ton John, I had almost given up.
> > > > > >
> > > > > > Yeah, First up i create the iframe url, which is like
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://shindig.company.com//app/shindig/gadgets/ifr?container=smx-con
> tainer&v=d84f1182fc1ef128c4c16095d561c3&lang=en&country=US&view=defaul
> t&up_appServiceCode=MY.CUSTOM.REPORT&up_chartTitle=My+Custom+Chart+For
> +Performance&up_reportSWFURL=https%3A%2F%2Flocalhost%3A8443%2Fapp%2Fco
> re%2Fmain%2Fswf%2Freporting.swf&up_reportingXmlStr=%3CreportPreference
> s%3E+%3Csettings%3E+%3CchartID%3Erankedbubblechart%3C%2FchartID%3E+%3C
> %2Fsettings%3E+%3Cquery%3E+%3CappServiceCode%3EMY.CUSTOM.REPORT%3C%2Fa
> ppServiceCode%3E+%3CfilterInstanceID%3EiNstance_fRom_tEmplate_11383%3C
> %2FfilterInstanceID%3E+%3Ctemplate%3Eacct-report-template.xml%3C%2Ftem
> plate%3E+%3CtimeHorizon%3E+%3CperiodTypeCode%3EHALFYEAR%3C%2FperiodTyp
> eCode%3E+%3CstartPeriod%2F%3E+%3CendPeriod%2F%3E+%3C%2FtimeHorizon%3E+
> %3C%2Fquery%3E%3C%2FreportPreferences%3E&url=https%3A%2F%2Fi-0029%3A84
> 43%2Fapp%2Fgadget%2Fcom.company.gadget.ReportingGadget%2Fcom.company.g
> adget.client.ReportingGadget.gadget.xml&libs=opensocial-0.8&parent=htt
> ps%3A%2F%2Fi-0029%3A8443%2Fapp%2Fcore%2Fmain%2F&nocache=0#rpctoken=0.2
> 649638729165247
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://i-0029:8443/https://i-0029:8443//app/shindig/gadgets/ifr?conta
> iner=smx-container&v=d84f1182fc1ef128c4c16095d561c3&lang=en&country=US
> &view=default&up_appServiceCode=MY.CUSTOM.REPORT&up_chartTitle=My+Cust
> om+Chart+For+Performance&up_reportSWFURL=https%3A%2F%2Flocalhost%3A844
> 3%2Fapp%2Fcore%2Fmain%2Fswf%2Freporting.swf&up_reportingXmlStr=%3Crepo
> rtPreferences%3E+%3Csettings%3E+%3CchartID%3Erankedbubblechart%3C%2Fch
> artID%3E+%3C%2Fsettings%3E+%3Cquery%3E+%3CappServiceCode%3EMY.CUSTOM.R
> EPORT%3C%2FappServiceCode%3E+%3CfilterInstanceID%3EiNstance_fRom_tEmpl
> ate_11383%3C%2FfilterInstanceID%3E+%3Ctemplate%3Eacct-report-template.
> xml%3C%2Ftemplate%3E+%3CtimeHorizon%3E+%3CperiodTypeCode%3EHALFYEAR%3C
> %2FperiodTypeCode%3E+%3CstartPeriod%2F%3E+%3CendPeriod%2F%3E+%3C%2Ftim
> eHorizon%3E+%3C%2Fquery%3E%3C%2FreportPreferences%3E&url=https%3A%2F%2
> Fi-0029%3A8443%2Fapp%2Fgadget%2Fcom.company.gadget.ReportingGadget%2Fc
> om.company.gadget.client.ReportingGadget.gadget.xml&libs=opensocial-0.
> 8&parent=https%3A%2F%2Fi-0029%3A8443%2Fapp%2Fcore%2Fmain%2F&nocache=0#
> rpctoken=0.2649638729165247
> > > > > > >
> > > > > >
> > > > > > then i set this as innerhtml to my gadget div and i follow
> > > > > > it up with
> > > > > >
> > > > > > gadgets.rpc.setRelayUrl(iframeId, iframeUrl, false);
> > > > > > gadgets.rpc.setAuthToken(iframeId, rpcToken);
> > > > > >
> > > > > > The browser versions having trouble are ie6 and ie7
> > > > > >
> > > > > > I tried
> > > > > > gadgets.rpc.setupReceiver(gadgetIFrameId);
> > > > > >
> > > > > > but it seems the method is not available in my version of
> > > > > > Shindig
> -
> > > > > > 1.1-Beta2
> > > > > >
> > > > > > Thanks in advance.
> > > > > >
> > > > > > Best Regards,
> > > > > > Hafiz
> > > > > >
> > > > > > 2009/11/20 John Hjelmstad <fargo@google.com>
> > > > > >
> > > > > > > Hi Hafiz:
> > > > > > >
> > > > > > > Order is everything. I want to confirm: you're first
> > > > > > > rendering
> > the
> > > > > > IFRAME,
> > > > > > > then immediately doing gadgets.rpc.setRelayUrl(...) and
> > > > > > > gadgets.rpc.setAuthToken(...) correct?
> > > > > > >
> > > > > > > To best deduce this issue, I'd need:
> > > > > > > 1. The exact IFRAME URL you're generating (you can remove
> > > > > > > the
> > > > security
> > > > > > > token
> > > > > > > if there is one)
> > > > > > > 2. The order in which you're generating the IFRAME URL
and
> > calling
> > > > the
> > > > > > > setup
> > > > > > > commands.
> > > > > > > 3. The browser version(s) you're using.
> > > > > > >
> > > > > > > As well, you might try
> gadgets.rpc.setupReceiver(gadgetIFrameId);
> > > -->
> > > > > > this
> > > > > > > is the replacement to setRelayUrl and setAuthToken which
> ensures
> > > > proper
> > > > > > > ordering.
> > > > > > >
> > > > > > > --j
> > > > > > >
> > > > > > > On Wed, Nov 18, 2009 at 11:39 PM, Hafiz A Haq <
> > hafizahaq@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > nix_channels[targetId] is not undefined, for the first
> > > > > > > > time
> > when
> > > i
> > > > > run
> > > > > > > the
> > > > > > > > app after a jboss restart... so basically the rpc
goes
> through
> > > for
> > > > > the
> > > > > > > > first
> > > > > > > > gadget(if and only there is one gadget request while
> > > > > > > > starting
> > > > up)...
> > > > > > > >
> > > > > > > > Any clue, why this happens?
> > > > > > > >
> > > > > > > > Thanks and Regards,
> > > > > > > > Hafiz
> > > > > > > >
> > > > > > > > 2009/11/18 Hafiz A Haq <hafizahaq@gmail.com>
> > > > > > > >
> > > > > > > > > Not sure if i am pestering you guys, but i dont
have
> > > > > > > > > any
> > other
> > > > > > > option...
> > > > > > > > > :-(
> > > > > > > > >
> > > > > > > > > I am also invoking
> > > > > > > > > gadgets.rpc.setRelayUrl(iframeId, iframeUrl,
false);
> > > > > > > > > gadgets.rpc.setAuthToken(iframeId, rpcToken);
> > > > > > > > >
> > > > > > > > > from the container for each gadget generated.
> > > > > > > > >
> > > > > > > > > and alert from nix.transport.js
> > > > > > > > >
> > > > > > > > > call: function(targetId, from, rpc) {
> > > > > > > > > try {
> > > > > > > > > // If we have a handler, call it.
> > > > > > > > > alert(targetId+" = "+nix_channels[targetId]+"
> > > > > > > > > from
> > > > "+from+"
> > > > > > rpc
> > > > > > > > is
> > > > > > > > > "+gadgets.json.stringify(rpc));
> > > > > > > > > ....
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > gives
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > .. = from remote_iframe_0 rpc
> > > > > > > > > {"s":"set_title","f":"remote_iframe_0","c":0,"a"["Acco
> > > > > > > > > unt overview"],"t":"0.6466592220939002","I":false}
> > > > > > > > >
> > > > > > > > > works (once in a blue moon)
> > > > > > > > >
> > > > > > > > > .. = undefined from remote_iframe_2 rpc is
> > > > > > > > > {"s":"set_title","f":"remote_iframe_2","c":0,"a":["Acc
> > > > > > > > > ount summary"],"t":"0.33673688496145","I":false}
> > > > > > > > >
> > > > > > > > > doesnt work
> > > > > > > > >
> > > > > > > > > I don't understand why most of the times the
undefined
> comes
> > up
> > > > and
> > > > > > > then
> > > > > > > > it
> > > > > > > > > fails...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Please , all those gurus and experts, any tip,
> > > > > > > > > something i
> > > might
> > > > be
> > > > > > > > > missing...
> > > > > > > > >
> > > > > > > > > Thanks and Regards,
> > > > > > > > > Hafiz
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2009/11/18 Hafiz A Haq <hafizahaq@gmail.com>
> > > > > > > > >
> > > > > > > > >> I have also added rpctoken into the iframeurl
like
> > > > > > > > >>
> > > > > > > > >> https://
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> .../ifr?container=...&lang=en&country=US&view=default&nocache=1&rpctok
> en=0.9956869901138398,
> > > > > > > > >> which is essentially a random number
> > > > > > > > >>
> > > > > > > > >> still the rpc calls are not getting through.
> > > > > > > > >>
> > > > > > > > >> Anything else i might be missing.
> > > > > > > > >>
> > > > > > > > >> 2009/11/18 Hafiz A Haq <hafizahaq@gmail.com>
> > > > > > > > >>
> > > > > > > > >> Any input would help me. Please provide a
hint why
> > > > > > > > >> nix
> > > transport
> > > > > > fails
> > > > > > > > >>> when container and shindig is at 2 different
secure
> > domains?
> > > > > > > > >>>
> > > > > > > > >>> 2009/10/28 Hafiz A Haq <hafizahaq@gmail.com>
> > > > > > > > >>>
> > > > > > > > >>>> Seems there is something that makes
the nix
> > > > > > > > >>>> transport
> > > > mechanism
> > > > > > fail
> > > > > > > > >>>> here, the call method is not going
through , where
> > > > > > > > >>>> it
> > fails
> > > at
> > > > > the
> > > > > > > > check
> > > > > > > > >>>> if (nix_channels[targetId])
> > > > > > > > >>>>
> > > > > > > > >>>> In the call method the parameters
targetId, from,
> > > > > > > > >>>> rpc
> > alerts
> > > > to
> > > > > > > > >>>> '.. , remote_iframe_3 , [object
Object]'
> > > > > > > > >>>>
> > > > > > > > >>>> Can anyone please give me a hint
why the code
> > > > > > > > >>>>
> > > > > > > > >>>> if (nix_channels[..])
> > > > > > > > >>>>
> > > > > > > > >>>> is not going through as expected..
> > > > > > > > >>>>
> > > > > > > > >>>> Any help is appreciated.
> > > > > > > > >>>>
> > > > > > > > >>>> Thanks and REgards, Hafiz
> > > > > > > > >>>>
> > > > > > > > >>>> 2009/10/28 Hafiz A Haq <hafizahaq@gmail.com>
> > > > > > > > >>>>
> > > > > > > > >>>> Hi All,
> > > > > > > > >>>>>
> > > > > > > > >>>>> My dashboard application is up
and running in
> production,
> > > > > thanks
> > > > > > to
> > > > > > > > >>>>> Shindig and you guys. Due to
some serious mistake
> > > > > > > > >>>>> from
> QA
> > > and
> > > > > IT
> > > > > > > guys
> > > > > > > > i have
> > > > > > > > >>>>> a bug at this last hour as rpc
feature is broken
> > > > > > > > >>>>> in
> > > > production
> > > > > > and
> > > > > > > my
> > > > > > > > >>>>> clients are not so happy.. :(
> > > > > > > > >>>>>
> > > > > > > > >>>>> In production each client has
individual
> > > > > > > > >>>>> subdomains and
> > > > shindig
> > > > > > is
> > > > > > > > >>>>> deployed in a common subdomain
for all customers,
> > > > > > > > >>>>> both
> > over
> > > > > > https.
> > > > > > > > RPC is
> > > > > > > > >>>>> now broken in IE6,7 and setTitle,
setHeight ...
> > > > > > > > >>>>> are not
> > > > > working.
> > > > > > > > >>>>>
> > > > > > > > >>>>> I assigned gadgets.parent in
myContainer.js with a
> regex
> > > > > pattern
> > > > > > > like
> > > > > > > > >>>>>
> > > > > > > > >>>>> "gadgets.parent" : "(https://localhost:8443|
> > > > > > > > >>>>> https://customer1.app.company.com|
> > > > > > > https://customer2.app.company.com
> > > > > > > > )",
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>> and rpc like
> > > > > > > > >>>>>
> > > > > > > > >>>>> "rpc" : {
> > > > > > > > >>>>> // Path to the relay file.
Automatically
> > > > > > > > >>>>> appended
> to
> > > the
> > > > > > parent
> > > > > > > > >>>>> // parameter if it passes
input validation and
> > > > > > > > >>>>> is
> not
> > > > null.
> > > > > > > > >>>>> // This should never be on
the same host in a
> > > production
> > > > > > > > >>>>> environment!
> > > > > > > > >>>>> // Only use this for TESTING!
> > > > > > > > >>>>> "parentRelayUrl" :
> > > > > > > > >>>>> "/app/core/main/rpc_relay.html",
> > > > > > > > >>>>>
> > > > > > > > >>>>> // If true, this will use
the legacy ifpc wire
> format
> > > > when
> > > > > > > making
> > > > > > > > >>>>> rpc
> > > > > > > > >>>>> // requests.
> > > > > > > > >>>>> "useLegacyProtocol" : false
> > > > > > > > >>>>> }
> > > > > > > > >>>>>
> > > > > > > > >>>>> Now i tried
> > > > > > > > >>>>>
> > > > > > > > >>>>> var parentRelayUrl = window.location.protocol
+
> > > > > > > > >>>>> "//" + window.location.host
> > > > > > > > >>>>> gadgets.container.setParentUrl(parentRelayUrl);
> > > > > > > > >>>>>
> > > > > > > > >>>>> from the container js file, which
is loaded after
> loading
> > > all
> > > > > > > > required
> > > > > > > > >>>>> shindig js file dependencies.
Still i am not able
> > > > > > > > >>>>> to
> get
> > > the
> > > > > rpcs
> > > > > > > to
> > > > > > > > work
> > > > > > > > >>>>> properly in IE6,7. Any help is
greatly appreciated
> > > > > > > > >>>>> as
> > some
> > > of
> > > > > my
> > > > > > > > customers
> > > > > > > > >>>>> are tied down on IE7.
> > > > > > > > >>>>>
> > > > > > > > >>>>> Best Regards,
> > > > > > > > >>>>> Hafiz
> > > > > > > > >>>>> --
> > > > > > > > >>>>> He who asks is a fool for five
minutes, but he who
> > > > > > > > >>>>> does
> > not
> > > > ask
> > > > > > > > remains
> > > > > > > > >>>>> a fool forever.
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>> --
> > > > > > > > >>>> He who asks is a fool for five minutes,
but he who
> > > > > > > > >>>> does
> > not
> > > > ask
> > > > > > > > remains
> > > > > > > > >>>> a fool forever.
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>> --
> > > > > > > > >>> He who asks is a fool for five minutes,
but he who
> > > > > > > > >>> does
> not
> > > ask
> > > > > > > remains
> > > > > > > > a
> > > > > > > > >>> fool forever.
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> --
> > > > > > > > >> He who asks is a fool for five minutes, but
he who
> > > > > > > > >> does
> not
> > > ask
> > > > > > > remains
> > > > > > > > a
> > > > > > > > >> fool forever.
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > He who asks is a fool for five minutes, but he
who
> > > > > > > > > does not
> > ask
> > > > > > remains
> > > > > > > a
> > > > > > > > > fool forever.
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > He who asks is a fool for five minutes, but he who
does
> > > > > > > > not
> ask
> > > > > remains
> > > > > > a
> > > > > > > > fool forever.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > He who asks is a fool for five minutes, but he who does not
> > > > > > ask
> > > remains
> > > > a
> > > > > > fool forever.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > He who asks is a fool for five minutes, but he who does not ask
> remains
> > a
> > > > fool forever.
> > > >
> > >
> >
> >
> >
> > --
> > He who asks is a fool for five minutes, but he who does not ask
> > remains a fool forever.
> >
>
--
He who asks is a fool for five minutes, but he who does not ask remains a fool forever.
Thank you John for the helping hand.
I just noticed one more strange behavior, probably is already discussed in
the thread - http://markmail.org/thread/zorpp3exisyei76w
When i maximize the gadget, i change the view to canvas, and the rpcs fail
in ie7. I could fix the issue by rerendering the gadget with a new moduleId.
Any recommendation on the proper fix for this one?
Thanks and Regards,
Hafiz
2009/12/1 John Hjelmstad <fargo@google.com>
> Hi Hafiz:
>
> Sounds like this has something to do with the way that numeric values are
> coerced to and from String values in JS. Forcing the value to be a String
> (w/ a non-numeric char) is a fine solution for the moment. A colleague
> recently saw this behavior as well. I'll take a look when I get some time.
>
> Let me know if you run into any other troubles-
>
> --j
>
> On Mon, Nov 30, 2009 at 11:32 PM, Hafiz A Haq <hafizahaq@gmail.com> wrote:
>
> > Seems appending a random character to the random number has fixed the
> > issue,
> > atleast in my dev environment.
> >
> > I will update you once the build makes it to production. Waiting with my
> > fingers crossed.
> >
> > Thanks and Regards,
> > Hafiz
> >
> > 2009/11/25 John Hjelmstad <fargo@google.com>
> >
> > > Throwing a few ideas out there:
> > >
> > > 1. Rather than your rpctoken being (interpreted as) a number, ensure
> it's
> > a
> > > string by prepending "A" or something to it.
> > > 2. Any chance VBScript is disabled for you?
> > >
> > > -j-
> > >
> > > On Sun, Nov 22, 2009 at 10:30 PM, Hafiz A Haq <hafizahaq@gmail.com>
> > wrote:
> > >
> > > > 2009/11/21 John Hjelmstad <fargo@google.com>
> > > >
> > > > > 1. Ah, version 1.1-beta2. I can't recall whether that version has
> the
> > > new
> > > > > NIX protocol in it or not. Does your /gadgets/js/rpc.js?c=1 file
> > > contain
> > > > > symbols named gadgets.rpctx.nix*?
> > > > >
> > > > >
> > > > I tried 1.1beta2 and 1.1beta4 , i could find something like
> > > >
> > > > gadgets.rpctx.nix=function(){var C="GRPC____NIXVBS_wrapper";
> > > >
> > > > 2. Do you have a special container config for container=smx-container
> > > that
> > > > > overrides any values for "gadgets.features":{"rpc"...?
> > > > >
> > > > >
> > > > "rpc" : {
> > > > // Path to the relay file. Automatically appended to the parent
> > > > /// parameter if it passes input validation and is not null.
> > > > // This should never be on the same host in a production
> > environment!
> > > > // Only use this for TESTING!
> > > > "parentRelayUrl" : "/app/core/main/rpc_relay.html",
> > > >
> > > > // If true, this will use the legacy ifpc wire format when making
> > rpc
> > > > // requests.
> > > > "useLegacyProtocol" : false
> > > > }
> > > >
> > > >
> > > > Anything amiss here?
> > > >
> > > > Thanks and Regards,
> > > > Hafiz
> > > >
> > > >
> > > > On Fri, Nov 20, 2009 at 4:51 AM, Hafiz A Haq <hafizahaq@gmail.com>
> > > wrote:
> > > > >
> > > > > > Thanks a ton John, I had almost given up.
> > > > > >
> > > > > > Yeah, First up i create the iframe url, which is like
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://shindig.company.com//app/shindig/gadgets/ifr?container=smx-container&v=d84f1182fc1ef128c4c16095d561c3&lang=en&country=US&view=default&up_appServiceCode=MY.CUSTOM.REPORT&up_chartTitle=My+Custom+Chart+For+Performance&up_reportSWFURL=https%3A%2F%2Flocalhost%3A8443%2Fapp%2Fcore%2Fmain%2Fswf%2Freporting.swf&up_reportingXmlStr=%3CreportPreferences%3E+%3Csettings%3E+%3CchartID%3Erankedbubblechart%3C%2FchartID%3E+%3C%2Fsettings%3E+%3Cquery%3E+%3CappServiceCode%3EMY.CUSTOM.REPORT%3C%2FappServiceCode%3E+%3CfilterInstanceID%3EiNstance_fRom_tEmplate_11383%3C%2FfilterInstanceID%3E+%3Ctemplate%3Eacct-report-template.xml%3C%2Ftemplate%3E+%3CtimeHorizon%3E+%3CperiodTypeCode%3EHALFYEAR%3C%2FperiodTypeCode%3E+%3CstartPeriod%2F%3E+%3CendPeriod%2F%3E+%3C%2FtimeHorizon%3E+%3C%2Fquery%3E%3C%2FreportPreferences%3E&url=https%3A%2F%2Fi-0029%3A8443%2Fapp%2Fgadget%2Fcom.company.gadget.ReportingGadget%2Fcom.company.gadget.client.ReportingGadget.gadget.xml&libs=opensocial-0.8&parent=https%3A%2F%2Fi-0029%3A8443%2Fapp%2Fcore%2Fmain%2F&nocache=0#rpctoken=0.2649638729165247
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://i-0029:8443/https://i-0029:8443//app/shindig/gadgets/ifr?container=smx-container&v=d84f1182fc1ef128c4c16095d561c3&lang=en&country=US&view=default&up_appServiceCode=MY.CUSTOM.REPORT&up_chartTitle=My+Custom+Chart+For+Performance&up_reportSWFURL=https%3A%2F%2Flocalhost%3A8443%2Fapp%2Fcore%2Fmain%2Fswf%2Freporting.swf&up_reportingXmlStr=%3CreportPreferences%3E+%3Csettings%3E+%3CchartID%3Erankedbubblechart%3C%2FchartID%3E+%3C%2Fsettings%3E+%3Cquery%3E+%3CappServiceCode%3EMY.CUSTOM.REPORT%3C%2FappServiceCode%3E+%3CfilterInstanceID%3EiNstance_fRom_tEmplate_11383%3C%2FfilterInstanceID%3E+%3Ctemplate%3Eacct-report-template.xml%3C%2Ftemplate%3E+%3CtimeHorizon%3E+%3CperiodTypeCode%3EHALFYEAR%3C%2FperiodTypeCode%3E+%3CstartPeriod%2F%3E+%3CendPeriod%2F%3E+%3C%2FtimeHorizon%3E+%3C%2Fquery%3E%3C%2FreportPreferences%3E&url=https%3A%2F%2Fi-0029%3A8443%2Fapp%2Fgadget%2Fcom.company.gadget.ReportingGadget%2Fcom.company.gadget.client.ReportingGadget.gadget.xml&libs=opensocial-0.8&parent=https%3A%2F%2Fi-0029%3A8443%2Fapp%2Fcore%2Fmain%2F&nocache=0#rpctoken=0.2649638729165247
> > > > > > >
> > > > > >
> > > > > > then i set this as innerhtml to my gadget div
> > > > > > and i follow it up with
> > > > > >
> > > > > > gadgets.rpc.setRelayUrl(iframeId, iframeUrl, false);
> > > > > > gadgets.rpc.setAuthToken(iframeId, rpcToken);
> > > > > >
> > > > > > The browser versions having trouble are ie6 and ie7
> > > > > >
> > > > > > I tried
> > > > > > gadgets.rpc.setupReceiver(gadgetIFrameId);
> > > > > >
> > > > > > but it seems the method is not available in my version of Shindig
> -
> > > > > > 1.1-Beta2
> > > > > >
> > > > > > Thanks in advance.
> > > > > >
> > > > > > Best Regards,
> > > > > > Hafiz
> > > > > >
> > > > > > 2009/11/20 John Hjelmstad <fargo@google.com>
> > > > > >
> > > > > > > Hi Hafiz:
> > > > > > >
> > > > > > > Order is everything. I want to confirm: you're first rendering
> > the
> > > > > > IFRAME,
> > > > > > > then immediately doing gadgets.rpc.setRelayUrl(...) and
> > > > > > > gadgets.rpc.setAuthToken(...) correct?
> > > > > > >
> > > > > > > To best deduce this issue, I'd need:
> > > > > > > 1. The exact IFRAME URL you're generating (you can remove
the
> > > > security
> > > > > > > token
> > > > > > > if there is one)
> > > > > > > 2. The order in which you're generating the IFRAME URL
and
> > calling
> > > > the
> > > > > > > setup
> > > > > > > commands.
> > > > > > > 3. The browser version(s) you're using.
> > > > > > >
> > > > > > > As well, you might try
> gadgets.rpc.setupReceiver(gadgetIFrameId);
> > > -->
> > > > > > this
> > > > > > > is the replacement to setRelayUrl and setAuthToken which
> ensures
> > > > proper
> > > > > > > ordering.
> > > > > > >
> > > > > > > --j
> > > > > > >
> > > > > > > On Wed, Nov 18, 2009 at 11:39 PM, Hafiz A Haq <
> > hafizahaq@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > nix_channels[targetId] is not undefined, for the first
time
> > when
> > > i
> > > > > run
> > > > > > > the
> > > > > > > > app after a jboss restart... so basically the rpc
goes
> through
> > > for
> > > > > the
> > > > > > > > first
> > > > > > > > gadget(if and only there is one gadget request while
starting
> > > > up)...
> > > > > > > >
> > > > > > > > Any clue, why this happens?
> > > > > > > >
> > > > > > > > Thanks and Regards,
> > > > > > > > Hafiz
> > > > > > > >
> > > > > > > > 2009/11/18 Hafiz A Haq <hafizahaq@gmail.com>
> > > > > > > >
> > > > > > > > > Not sure if i am pestering you guys, but i dont
have any
> > other
> > > > > > > option...
> > > > > > > > > :-(
> > > > > > > > >
> > > > > > > > > I am also invoking
> > > > > > > > > gadgets.rpc.setRelayUrl(iframeId, iframeUrl,
false);
> > > > > > > > > gadgets.rpc.setAuthToken(iframeId, rpcToken);
> > > > > > > > >
> > > > > > > > > from the container for each gadget generated.
> > > > > > > > >
> > > > > > > > > and alert from nix.transport.js
> > > > > > > > >
> > > > > > > > > call: function(targetId, from, rpc) {
> > > > > > > > > try {
> > > > > > > > > // If we have a handler, call it.
> > > > > > > > > alert(targetId+" = "+nix_channels[targetId]+"
from
> > > > "+from+"
> > > > > > rpc
> > > > > > > > is
> > > > > > > > > "+gadgets.json.stringify(rpc));
> > > > > > > > > ....
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > gives
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > .. = from remote_iframe_0 rpc
> > > > > > > > > {"s":"set_title","f":"remote_iframe_0","c":0,"a"["Account
> > > > > > > > > overview"],"t":"0.6466592220939002","I":false}
> > > > > > > > >
> > > > > > > > > works (once in a blue moon)
> > > > > > > > >
> > > > > > > > > .. = undefined from remote_iframe_2 rpc is
> > > > > > > > > {"s":"set_title","f":"remote_iframe_2","c":0,"a":["Account
> > > > > > > > > summary"],"t":"0.33673688496145","I":false}
> > > > > > > > >
> > > > > > > > > doesnt work
> > > > > > > > >
> > > > > > > > > I don't understand why most of the times the
undefined
> comes
> > up
> > > > and
> > > > > > > then
> > > > > > > > it
> > > > > > > > > fails...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Please , all those gurus and experts, any tip,
something i
> > > might
> > > > be
> > > > > > > > > missing...
> > > > > > > > >
> > > > > > > > > Thanks and Regards,
> > > > > > > > > Hafiz
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2009/11/18 Hafiz A Haq <hafizahaq@gmail.com>
> > > > > > > > >
> > > > > > > > >> I have also added rpctoken into the iframeurl
like
> > > > > > > > >>
> > > > > > > > >> https://
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> .../ifr?container=...&lang=en&country=US&view=default&nocache=1&rpctoken=0.9956869901138398,
> > > > > > > > >> which is essentially a random number
> > > > > > > > >>
> > > > > > > > >> still the rpc calls are not getting through.
> > > > > > > > >>
> > > > > > > > >> Anything else i might be missing.
> > > > > > > > >>
> > > > > > > > >> 2009/11/18 Hafiz A Haq <hafizahaq@gmail.com>
> > > > > > > > >>
> > > > > > > > >> Any input would help me. Please provide a
hint why nix
> > > transport
> > > > > > fails
> > > > > > > > >>> when container and shindig is at 2 different
secure
> > domains?
> > > > > > > > >>>
> > > > > > > > >>> 2009/10/28 Hafiz A Haq <hafizahaq@gmail.com>
> > > > > > > > >>>
> > > > > > > > >>>> Seems there is something that makes
the nix transport
> > > > mechanism
> > > > > > fail
> > > > > > > > >>>> here, the call method is not going
through , where it
> > fails
> > > at
> > > > > the
> > > > > > > > check
> > > > > > > > >>>> if (nix_channels[targetId])
> > > > > > > > >>>>
> > > > > > > > >>>> In the call method the parameters
targetId, from, rpc
> > alerts
> > > > to
> > > > > > > > >>>> '.. , remote_iframe_3 , [object
Object]'
> > > > > > > > >>>>
> > > > > > > > >>>> Can anyone please give me a hint
why the code
> > > > > > > > >>>>
> > > > > > > > >>>> if (nix_channels[..])
> > > > > > > > >>>>
> > > > > > > > >>>> is not going through as expected..
> > > > > > > > >>>>
> > > > > > > > >>>> Any help is appreciated.
> > > > > > > > >>>>
> > > > > > > > >>>> Thanks and REgards,
> > > > > > > > >>>> Hafiz
> > > > > > > > >>>>
> > > > > > > > >>>> 2009/10/28 Hafiz A Haq <hafizahaq@gmail.com>
> > > > > > > > >>>>
> > > > > > > > >>>> Hi All,
> > > > > > > > >>>>>
> > > > > > > > >>>>> My dashboard application is up
and running in
> production,
> > > > > thanks
> > > > > > to
> > > > > > > > >>>>> Shindig and you guys. Due to
some serious mistake from
> QA
> > > and
> > > > > IT
> > > > > > > guys
> > > > > > > > i have
> > > > > > > > >>>>> a bug at this last hour as rpc
feature is broken in
> > > > production
> > > > > > and
> > > > > > > my
> > > > > > > > >>>>> clients are not so happy.. :(
> > > > > > > > >>>>>
> > > > > > > > >>>>> In production each client has
individual subdomains and
> > > > shindig
> > > > > > is
> > > > > > > > >>>>> deployed in a common subdomain
for all customers, both
> > over
> > > > > > https.
> > > > > > > > RPC is
> > > > > > > > >>>>> now broken in IE6,7 and setTitle,
setHeight ... are not
> > > > > working.
> > > > > > > > >>>>>
> > > > > > > > >>>>> I assigned gadgets.parent in
myContainer.js with a
> regex
> > > > > pattern
> > > > > > > like
> > > > > > > > >>>>>
> > > > > > > > >>>>> "gadgets.parent" : "(https://localhost:8443|
> > > > > > > > >>>>> https://customer1.app.company.com|
> > > > > > > https://customer2.app.company.com
> > > > > > > > )",
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>> and rpc like
> > > > > > > > >>>>>
> > > > > > > > >>>>> "rpc" : {
> > > > > > > > >>>>> // Path to the relay file.
Automatically appended
> to
> > > the
> > > > > > parent
> > > > > > > > >>>>> // parameter if it passes
input validation and is
> not
> > > > null.
> > > > > > > > >>>>> // This should never be on
the same host in a
> > > production
> > > > > > > > >>>>> environment!
> > > > > > > > >>>>> // Only use this for TESTING!
> > > > > > > > >>>>> "parentRelayUrl" : "/app/core/main/rpc_relay.html",
> > > > > > > > >>>>>
> > > > > > > > >>>>> // If true, this will use
the legacy ifpc wire
> format
> > > > when
> > > > > > > making
> > > > > > > > >>>>> rpc
> > > > > > > > >>>>> // requests.
> > > > > > > > >>>>> "useLegacyProtocol" : false
> > > > > > > > >>>>> }
> > > > > > > > >>>>>
> > > > > > > > >>>>> Now i tried
> > > > > > > > >>>>>
> > > > > > > > >>>>> var parentRelayUrl = window.location.protocol
+ "//" +
> > > > > > > > >>>>> window.location.host
> > > > > > > > >>>>> gadgets.container.setParentUrl(parentRelayUrl);
> > > > > > > > >>>>>
> > > > > > > > >>>>> from the container js file, which
is loaded after
> loading
> > > all
> > > > > > > > required
> > > > > > > > >>>>> shindig js file dependencies.
Still i am not able to
> get
> > > the
> > > > > rpcs
> > > > > > > to
> > > > > > > > work
> > > > > > > > >>>>> properly in IE6,7. Any help is
greatly appreciated as
> > some
> > > of
> > > > > my
> > > > > > > > customers
> > > > > > > > >>>>> are tied down on IE7.
> > > > > > > > >>>>>
> > > > > > > > >>>>> Best Regards,
> > > > > > > > >>>>> Hafiz
> > > > > > > > >>>>> --
> > > > > > > > >>>>> He who asks is a fool for five
minutes, but he who does
> > not
> > > > ask
> > > > > > > > remains
> > > > > > > > >>>>> a fool forever.
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>> --
> > > > > > > > >>>> He who asks is a fool for five minutes,
but he who does
> > not
> > > > ask
> > > > > > > > remains
> > > > > > > > >>>> a fool forever.
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>> --
> > > > > > > > >>> He who asks is a fool for five minutes,
but he who does
> not
> > > ask
> > > > > > > remains
> > > > > > > > a
> > > > > > > > >>> fool forever.
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> --
> > > > > > > > >> He who asks is a fool for five minutes, but
he who does
> not
> > > ask
> > > > > > > remains
> > > > > > > > a
> > > > > > > > >> fool forever.
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > He who asks is a fool for five minutes, but he
who does not
> > ask
> > > > > > remains
> > > > > > > a
> > > > > > > > > fool forever.
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > He who asks is a fool for five minutes, but he who
does not
> ask
> > > > > remains
> > > > > > a
> > > > > > > > fool forever.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > He who asks is a fool for five minutes, but he who does not
ask
> > > remains
> > > > a
> > > > > > fool forever.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > He who asks is a fool for five minutes, but he who does not ask
> remains
> > a
> > > > fool forever.
> > > >
> > >
> >
> >
> >
> > --
> > He who asks is a fool for five minutes, but he who does not ask remains a
> > fool forever.
> >
>
--
He who asks is a fool for five minutes, but he who does not ask remains a
fool forever.
Paul & Louis,
Thanks for your help. It is really appreciated!
I found the config you mentionned in container.js and was able to solve
my problem.
Turns out I had changed the following line in SocialAPIGuiceModule.java:
bind(Boolean.class)
.annotatedWith(Names.named(AnonymousAuthenticationHandler.ALLOW_UNAUTHENTICATED))
.toInstance(Boolean.TRUE);
to FALSE.
And the call to social/rpc was failing due to authentication, with the
following message:
{"message":"unauthorized: The request did not have a proper security
token nor oauth message and unauthenticated requests are not
allowed","code":401}
I set it to TRUE and it is now allowing that call to be completed.
However, it is also allowing all calls to my REST endpoints to be
accessed without authentication and I would like to prevent that.
How can I let the social/rpc introspection call go through without
authentication without removing authentication for all my REST
endpoints?
Thank you,
Luc
On Mon, 2009-11-30 at 11:40 -0800, Louis Ryan wrote:
> Luc
>
> You may be better off directly defining the exposed JSON-RPC services in
> your Shindig container.js rather than relying on the service introspection.
> This is documented inside the sample container.js file provided with
> Shindig.
>
> -Louis
>
> On Mon, Nov 30, 2009 at 9:31 AM, Paul Lindner <lindner@inuus.com> wrote:
>
> > When shindig starts it makes a request to to /social/rpc to get the list of
> > available methods. See container.js sections "osapi" and "osapi.services"
> > for ways to hard-code the list or change the endpoints used.
> >
> >
> > On Mon, Nov 30, 2009 at 6:18 AM, Luc Arthur Castera
> > <luc.castera@gmail.com>wrote:
> >
> > > Paul,
> > >
> > > When I load the gadget that uses osapi.people, I get a javascript error
> > in
> > > Firebug: osapi.people is undefined
> > >
> > > I also see the following warning coming from rpc.js: Unknown RPC service:
> > > osapi._handleGadgetRpcMethod
> > >
> > > On the shindig logs, I see the following error:
> > >
> > > Nov 30, 2009 9:06:59 AM
> > > org.apache.shindig.gadgets.render.DefaultServiceFetcher retrieveServices
> > > SEVERE: Failed to parse services methods from endpoint
> > > http://localhost:8080/social/rpc. JSONObject["data"] not found.
> > >
> > > My environment is the following:
> > > - Ubuntu 9.10
> > > - Java 1.6.0_16
> > > - Java version of Shindig (Trunk: SVN Revision 818615)
> > >
> > > I appreciate your help with this,
> > >
> > > Luc
> > >
> > >
> > >
> > > On Fri, Nov 27, 2009 at 5:45 AM, Paul Lindner <lindner@inuus.com> wrote:
> > >
> > > > osapi should 'just work' if you specify <Require feature="osapi"/>
in
> > > your
> > > > ModulePrefs. What behavior are you observing? Do you get the osapi
> > > classes
> > > > loaded? Is there any error with 'listMethods' in your shindig logs?
> > > >
> > > > Can you provide more information about your environment? Java/PHP?
> > > > Javascript Errors? etc....
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > On Wed, Nov 25, 2009 at 5:10 PM, Luc Arthur Castera
> > > > <luc.castera@gmail.com>wrote:
> > > >
> > > > > Hey,
> > > > >
> > > > > I wrote a gadget that uses the OS lite api (osapi.people,
> > > osapi.appdata,
> > > > > etc...). When I test the gadget on iGoogle, it works fine but when
I
> > > try
> > > > it
> > > > > on my local shindig instance, it is not working properly. It looks
> > like
> > > > the
> > > > > osapi.people and osapi.appdata are not implemented in Shindig.
> > > > >
> > > > > FYI, I have written my adapters for my local shindig instance and
I
> > am
> > > > able
> > > > > to use the older JS APIs without any issue.
> > > > >
> > > > > Are we suppose to implement the osapi.js libraries ourselves when
we
> > > > build
> > > > > our container or is it just that the shindig implementation hasn't
> > > > > implemented these newer APIs yet?
> > > > >
> > > > > Any pointers of the issue would be greatly helpful. I tried to search
> > > the
> > > > > mailing list but could not find anything on that matter.
> > > > >
> > > > > Thank you,
> > > > >
> > > > > Luc
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ______________________
> > > Luc Castera
> > >
> >
--
______________________
Luc Castera
Founder, ShareMeme Inc.
http://messagepub.com
Phone: 786-877-3789
Skype: luc.castera
Just so that it is known, more on the design: I'm taking liberty in
defining "URL gadget JS API" based on:
*) Shindig does not support anything today.
*) Very few actual server implementations for URL gadgets exist
*) Our experience with URL gadgets. Our implementation has quite a few
URL gadgets, but the implementation is propriety
*) You cannot support cross domain XMLHttpRequests - no makeRequest
etc...
Just to go a bit further...
Just about every URL gadget author will have a multi-page URL gadget.
That is one which the location URL changes over time. That's just the
typical pattern for these type of applications. We must make the
interface work for them, and be relatively easy for them to implement.
I believe that full API support using libs, would require either:
*) A really long lib URL
*) Maintenance of session state on the server
*) A complex calling procedure
None of the above are really good.
But if we narrow down the scope of the API to simply what cannot be
replaced by typical URL server side code, it then becomes easier.
For an example, think about how one would do message bundles
Prefs.getMsg? (These need user prefs for hangman substitution)
Then think, does a URL gadget developer even need this? (They don't,
I18N is done differently for URL apps)
Jon
-----Original Message-----
From: Weygandt, Jon [mailto:jweygandt@ebay.com]
Sent: Tuesday, December 01, 2009 8:14 AM
To: shindig-dev@incubator.apache.org
Subject: RE: Next step towards URL gadgets - design proposal
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.Shtein@Metavante.com [mailto:Ilya.Shtein@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" <jweygandt@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.Shtein@Metavante.com [mailto:Ilya.Shtein@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" <jweygandt@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.
---------------------------------------------------------------------
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.Shtein@Metavante.com [mailto:Ilya.Shtein@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" <jweygandt@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.Shtein@Metavante.com [mailto:Ilya.Shtein@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" <jweygandt@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.
---------------------------------------------------------------------