I understand the security token the gadget uses (the one returned on the
iframe url) is auto-refreshed when using the common-container. However,
I think the other part of Peter's question was that the rpc transport
uses the security token from shindig.auth and not the one from the
gadget. So how do you rectify this?
My understanding is that my container will generate a security token
that will be used by the rpc json requests required to get the gadget
setup (by calling shindig.auth.updateSecurityToken). Once the gadget is
setup it will use it's security token (different from the container one)
that is returned on the metadata response (st) to make it's requests.
Gadgets SHOULD NOT call shindig.auth.getSecurityToken()) is my
understanding. That's a container concept.
Any understanding on the Security Token flow is welcome. I asked a
and I appreciate Augustin's response about not confusing all this with
oauth and Justin's response about how they implemented security tokens
within their authenticated server. I am somewhat confused as to how the
token is secure (even if encrypted), since it can be sniffed and
replayed by someone else to make destructive rpc calls. Unless just the
expiration timeout of the token is enough.
But I still feel like I am missing something here.