Re: ³Invalid auth token.²after going backward/forward in browser

[Youri op 't Roodt <yo...@hyves.nl>]

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" <be...@google.com> wrote:

> On Tue, Sep 30, 2008 at 7:16 AM, Vjekoslav Nesek <vn...@nmote.com> 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.

Re: ³Invalid auth token.² after going backward/forward in browser

[Chris Chabot <ch...@google.com>]

If i remember correctly, the javascript libs don't mind at all if you do a
&rpctoken=<foo> instead of a #rpctoken=<foo>, no need to add a second random
value :)

   -- Chris

On Wed, Oct 1, 2008 at 9:42 AM, Youri op 't Roodt <yo...@hyves.nl> wrote:

> 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" <be...@google.com> wrote:
>
> > On Tue, Sep 30, 2008 at 7:16 AM, Vjekoslav Nesek <vn...@nmote.com>
> 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.
>
>