Using the new auth-refresh gadget feature

[Taylor Singletary]

Hi All,

I¹m wondering on the best way to implement auth-refresh feature
functionality. From the examples I¹ve seen in SHINDIG-655 (
https://issues.apache.org/jira/browse/SHINDIG-655?page=com.atlassian.jira.pl
ugin.ext.subversion%3Asubversion-commits-tabpanel ), I¹m still a bit unclear
as to practical use case scenarios, as well as how to setup tests for this.

Here are the use cases I¹m wondering about:

1. Container wants to refresh the security token on demand, whenever the
security token has expired. Does this mean that we should a) add Javascript
code before a security-token requiring function is executing to determine if
the token has expired and then call the RPC function to update the token
transparently to the gadget developer, b) this is already wired in when the
feature is required (from code I¹ve seen, this would not be the case).
2. Gadget developer wants to refresh the security token on demand, usually
before the original token has expired, through a javascript timeout
function.

If a gadget was wanting to make use of this feature, would this be the
proper way to invoke it?

        var currentToken = "";
        
        function refreshAuthToken() {
          setOriginalToken();
          gadgets.rpc.call(null, "update_security_token",
checkSecurityToken, null);
        };
        
        function getSecurityToken() {
          return shindig.auth.getSecurityToken();
        };
        
        function setOriginalToken() {
          currentToken = getSecurityToken();
        };
        
        function checkSecurityToken(new_token) {
          console.warn("Should have a new token.");
          console.warn("Original Token: " + currentToken);
          console.warn("New token: " + getSecurityToken() );
        };

Thanks,
Taylor