Of course. Common container takes care of security token refresh in the background, when a gadget is navigated (or preloaded). It updates gadgets security token by fetching new values (with some determined interval) and pushing them into gadgets via gadgets.rpc. This security token refresh will only work if there is at least one gadget navigated, requiring feature=auth-refresh, or listens to "update_security_token" rpc service.
On Mon, Jan 17, 2011 at 8:48 PM, Paul Lindner <[email protected]> wrote: > +mhermanto > > Michael does common container do anything to alleviate this? > > > 2010/12/7 Peter Rothenpieler <[email protected]>: > > Hi people of shindig, > > > > I am using OSAPI over JSON-RPC to load and store the Gadget > > UserPreferences as ApplicationData. On my demo-page, I have multiple > > gadgets being displayed at the same time (in iframes). Sadly, I have to > > "manually" update the securityToken for each call, since only one > > "global" SecurityToken is stored in the shindig.auth classes. > > This, of course, not only affects my UserPreferenceStore but also every > > OSAPI-Call which the gadget developers would make - they would all have > > to manually update the key by first calling > > "shindig.auth.updateSecurityToken(gadget.secureToken)". > > > > The problem is in "features/osapi/jsonrpctransport.js" where the osapi > > call is secured using the securityToken, which is obtained by calling > > "shindig.auth.getSecurityToken();" > > > >> function execute(requests, callback) { > >> [...] > >> var token = shindig.auth.getSecurityToken(); > >> if (token) { > >> url += "?st="; > >> url += encodeURIComponent(token); > >> } > >> [...] > > > > My AppDataCall looks like this: > >> shindig.AppDataBasedUserPrefStore.prototype.savePrefs = function(gadget) > { > >> shindig.auth.updateSecurityToken(gadget.secureToken); > >> osapi.appdata.update({ > >> appId: "UP_" + gadget.id, > >> userId: "@me", > >> groupId:"@self", > >> data: getUserPrefs()} > >> ).execute(savePrefsResponseHandler); > >> } > > > > Is there a better way to handle the SecurityToken when making > > OSAPI-Calls? Since gadget.secureToken is properly initialized - wouldn't > > it make sense to use this Token instead of the "shindig.auth" call? > > > > -Peter > > > > > > -- > Paul Lindner -- [email protected] -- linkedin.com/in/plindner >
