Right now, the restful java server does not fetch the security token from the url and does not use it. So, in order to have any working code for the wip restful js container I have to parse the viewer and owner ids out of the security token so i can pass them to the container directly. This definitely won't work in real life but is a placeholder until we get more restful impl stuff done.
When the restful impl is finished the js will pass the whole st up to the server blindly, just like it does on the json side. And at that point it will use special @viewer and @owner tokens so that it does not have to figure out how the owner and viewer are. As for your earlier thread, removing .st from the getUrlParameters will break people using Shindig. (including the company we work for) So... we'll need to handle that nicely somehow. - Cassie On Mon, May 12, 2008 at 5:24 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 5:22 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: >> This code seems pretty useless to me. I think the ideal way to get the >> viewer / owner / app id would be to do one of the following: >> >> - Pass them unencrypted into iframe params (encourages developers to rely on >> them being there or to not use signed / oauth requests, which is bad) >> - Retrieve them from the parent page using gadgets.rpc (my preferred >> solution) >> - Retrieve them from the social data service > > I like the third option, since it can be efficiently implemented using > either of the first two mechanisms. The social data API should be > able to answer questions about owner and viewer id without requiring > round trips to the server (or the container page, for that matter.) > > The comment in the code about special @viewer and @owner tokens in the > RESTful spec seemed like a reasonable option as well. >
