For now I've settled with a member-and-time-limited token because it has taken me quite some time already.
But, as I am re-reading your e-mail it makes perfect sense. Only the variables/tokens after the hash (#) change, but not the url itself. I've completely overlooked this. So I guess I should add some random value to the url, just to force the browser to reload the gadget? Thanks Brian! On 10/1/08 12:31 AM, "Brian Eaton" <[EMAIL PROTECTED]> wrote: > On Tue, Sep 30, 2008 at 7:16 AM, Vjekoslav Nesek <[EMAIL PROTECTED]> wrote: >> As a workaround, just use a constant... generated server side. I'm not sure >> what security >> implications are though. > > The security implications vary depending on what data is being passed > over the gadgets.rpc channel. If you care about the data (e.g. it's > user preferences), don't use a constant value. > > This really calls for debugging, not hacking around the problem. I > can't reproduce this, but if you can come up with a reproducible test > case I'll help troubleshoot. > > My guess is that the issue has something to do with the browser cache. > Maybe something like this? > > Parent page loads iframe like http://modules.com/gadget/ifr?...#rpctoken=12345 > > Parent page changes, loads liframe like > http://modules.com/gadgets/ifr?...#rpctoken=67890. > > Browser fails to reload gadget, since the URL did not change, just the > fragment. > > Gadget keeps using old RPC token.
