Hi Robby,
Please direct future questsions to this mailing list. JIRA is an issue
tracking system, not a help line. Here's some help though:
My questions:
> a. Where does the data come from?
This is implementation specific. The general flow is this:
- Container passes security token to the gadget iframe
- If the gadget needs access to social data, a separate request is made back
to the container to get this data. This can be done using a custom
gadgets.rpc call to talk to the container, an XHR to some back end service,
or whatever means makes sense for your site. Right now there is no
"standard" way to go about doing this, but Cassie is working on coming up
with one.
- Data is populated in social data structures and made available to the
gadget.
The current implementation of opensocial-0.7 in shindig just uses hard coded
data. Production sites will have to provide their own
opensocial-0.7implementation to actually be useful until Cassie's work
is complete.
> b. Does it come from url query #st=...? --(i saw it's encoded)
st (Security Token) is provided because the iframe won't have access to
normal credentials such as cookies.
c. How does container make the user data available for the "#st" value?
This is up to the data. Most sites encrypt owner, viewer, and app ids and
pass them in the security token. A trivial example in PHP might be something
like this:
$st = $crypter->encrypt(serialize(array('ownerId'=>$owner,
'viewerId'=>$viewer, 'appId'=>$appid)));
> d. How does gadget server parse "#st" value?
It doesn't. It's an opaque token that the gadget server passes around. The
only time the gadget server ever does anything with this value itself is
when making AUTHENTICATED or SIGNED calls. If you need to support these
calls (and most large sites probably do), you'll have to provide your own
GadgetSigner implementation and wire it up with a CrossServletState.
