Working on it now.
On Mon, Mar 10, 2008 at 2:58 PM, Cassie <[EMAIL PROTECTED]> wrote:
> awesome, so if you check this in then magically everything will be happy!
> hope you get that large thing in soon...
>
>
> On Mon, Mar 10, 2008 at 9:54 PM, Arne Roomann-Kurrik <[EMAIL PROTECTED]>
> wrote:
>
> > Great, thanks for including that!
> >
> > ~Arne
> >
> >
> > On Mon, Mar 10, 2008 at 12:31 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> >
> > > In my big patch (SHINDIG-118 I think) I've come up with what I think
> is
> > a
> > > solution that works:
> > >
> > > - gadgets.js always sets parent = http://<document.location.host>
> > > - default syndicator is set to /gadgets/...
> > >
> > > This allows everything to work fine "out of the box", and even on
> > > arbitrary
> > > domains as long as the /gadgets/ context path is consistent. If you
> > change
> > > this, you have to modify your syndicator config.
> > >
> > > verified this on all sample pages + samplecontainer and it seemed to
> > work.
> > >
> > > On Mon, Mar 10, 2008 at 11:06 AM, Arne Roomann-Kurrik <
> [EMAIL PROTECTED]
> > >
> > > wrote:
> > >
> > > > 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.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ~Kevin
> > >
> >
>
--
~Kevin
