I've been getting the same problem when viewing my demo in the
samplecontainer, so I've just been using the /gadgets/ifr url to show the
gadget rendering full-screen. (Force-reload isn't working for me either).
I haven't tested Chris' workaround since the demo (this afternoon) is going
to be downloading shindig from svn and building it, I don't want to get
people confused by applying my own patches to the source during the demo.
That being said, I can play around with things a bit later today - Chris, if
you post your patch again (I guess in JIRA?) I'll see if it fixes the
problem I'm seeing.
~Arne
On Mon, Mar 10, 2008 at 10:39 AM, Cassie <[EMAIL PROTECTED]> wrote:
> Hmm... so force-reloading wasn't working for my java based container.
> And also, your attached diff unfortunately didn't make it through.
>
> Perhaps this is just a me-only problem, has anybody else gotten this to
> work?
> Thanks.
>
> - Cassie
>
>
> On Sun, Mar 9, 2008 at 4:37 PM, Chris Chabot <[EMAIL PROTECTED]> wrote:
>
> > I've been able to confirm this by adding a &time=<time in ms> to the
> > IFRAME src tag (in the javascript/container/gadgets.js
> > gadgets.IfrGadget.prototype.getIframeUrl function)
> >
> > I've attached a diff for what works for me here locally. It's probably
> not
> > the right way to fix it but something of a work-around, but at least
> with
> > this the samples are working correctly for me :)
> >
> > Oh ps, sample7.html wasn't working for me either while for instance
> > sample2.html was (both with a config that included a /gadgets/files/...
> > parentRelayUr), it turns out the difference between the two is that
> sample7
> > includes:
> >
> > gadgets.container.setParentUrl("http://"; + document.location.host+
> > '/');
> >
> > And hence the final url was http://myhost//gadgets/... (notice the
> double
> > /, which made the (php-) server break), by removing this line everything
> > worked as it was supposed to again.
> >
> >
> > -- Chris
> >
> >
> >
> >
> >
> > On Mar 9, 2008, at 3:38 PM, Chris Chabot wrote:
> >
> > I got the same problem here with the sample?.html files: "Invalid auth
> > > token", and it might be a PHP shindig only problem i have here that
> > > coincidentally gives the same error, but maybe it's not coincidence so
> i'll
> > > post what i've found here anyhow :)
> > >
> > > Basically what i've found with some console.log'ing is that on a first
> > > page load (or forced reload) i get (console.log("auth comp:
> > > "+authToken[rpc.f]+" = "+rpc.t);)
> > >
> > > auth comp: 1185834238 = 1185834238
> > >
> > > but when i do a 'soft reload' (so no forced reload) i get:
> > >
> > > auth comp: 201272794 = 1185834238
> > >
> > > So it's still using the old token from the previous request, hence the
> > > token's aren't identical, and you get an auth token error.
> > >
> > > Since the original report said that when Arne changed the URL it
> worked,
> > > now it might not have been a absolute vs relative URL problem, but
> just have
> > > forced the browser to reload the frame's, and hence working again (a
> second
> > > refresh after that would've shown i think that it was still 'broken')
> > >
> > > -- Chris
> > >
> > >
> > > On Mar 7, 2008, at 9:45 PM, Kevin Brown wrote:
> > >
> > >
> > > > It shouldn't -- auth token validation is based on the iframe id, not
> > > > the
> > > > url. I'll take a look.
> > > >
> > > >
> > > >
> > > >
> >
> >
>
