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.
