You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@shindig.apache.org by Peter Rothenpieler <ro...@itm.uni-luebeck.de> on 2010/12/07 09:50:08 UTC
Gadget-specific SecurityToken for OSAPI?
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
Re: Gadget-specific SecurityToken for OSAPI?
Posted by Michael Hermanto <mh...@google.com>.
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 <li...@inuus.com> wrote:
> +mhermanto
>
> Michael does common container do anything to alleviate this?
>
>
> 2010/12/7 Peter Rothenpieler <ro...@itm.uni-luebeck.de>:
> > 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 -- lindner@inuus.com -- linkedin.com/in/plindner
>
Re: Gadget-specific SecurityToken for OSAPI?
Posted by Michael Hermanto <mh...@google.com>.
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 <li...@inuus.com> wrote:
> +mhermanto
>
> Michael does common container do anything to alleviate this?
>
>
> 2010/12/7 Peter Rothenpieler <ro...@itm.uni-luebeck.de>:
> > 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 -- lindner@inuus.com -- linkedin.com/in/plindner
>
Re: Gadget-specific SecurityToken for OSAPI?
Posted by Paul Lindner <li...@inuus.com>.
+mhermanto
Michael does common container do anything to alleviate this?
2010/12/7 Peter Rothenpieler <ro...@itm.uni-luebeck.de>:
> 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 -- lindner@inuus.com -- linkedin.com/in/plindner