Hi, I looked into shindig code figure out what could cause the INVALID_GADGET_TOKEN error,
The following patch helped me to figure it out:
diff -r be446a9e9ff5
modules/shindig_integrator/shindig/php/src/common/sample/BasicBlobCrypter.php
---
a/modules/shindig_integrator/shindig/php/src/common/sample/BasicBlobCrypter.php
Thu Feb 25 14:40:49 2010 +0100
+++
b/modules/shindig_integrator/shindig/php/src/common/sample/BasicBlobCrypter.php
Thu Mar 11 14:41:48 2010 +0100
@@ -128,8 +128,15 @@
$minTime = (int)$out[$this->TIMESTAMP_KEY] - $this->CLOCK_SKEW_ALLOWANCE;
$maxTime = (int)$out[$this->TIMESTAMP_KEY] + $maxAge +
$this->CLOCK_SKEW_ALLOWANCE;
$now = time();
+ $clock_skew_allowance = $this->CLOCK_SKEW_ALLOWANCE;
+ $timestamp_key = $this->TIMESTAMP_KEY;
+ $out_json = json_encode($out);
+ $minTimeStr = strftime("%Y-%m-%d %H:%M:%S", $minTime);
+ $maxTimeStr = strftime("%Y-%m-%d %H:%M:%S", $maxTime);
+ $nowStr = strftime("%Y-%m-%d %H:%M:%S", $now);
+ $timestampStr = strftime("%Y-%m-%d %H:%M:%S",
(int)$out[$this->TIMESTAMP_KEY]);
if (! ($minTime < $now && $now < $maxTime)) {
- throw new BlobExpiredException("Security token expired");
+ throw new BlobExpiredException("Security token expired: maxAge: $maxAge
clock_skew_allowance: $clock_skew_allowance timestamp_key: $timestamp_key out:
$out_json timestamp:\
$timestampStr ! $minTimeStr < $nowStr < $maxTimeStr");
}
}
}
diff -r be446a9e9ff5
modules/shindig_integrator/shindig/php/src/common/sample/BasicSecurityTokenDecoder.php
---
a/modules/shindig_integrator/shindig/php/src/common/sample/BasicSecurityTokenDecoder.php
Thu Feb 25 14:40:49 2010 +0100
+++
b/modules/shindig_integrator/shindig/php/src/common/sample/BasicSecurityTokenDecoder.php
Thu Mar 11 14:41:48 2010 +0100
@@ -34,7 +34,7 @@
*/
public function createToken($stringToken) {
if (empty($stringToken) && ! empty($_GET['authz'])) {
- throw new GadgetException('INVALID_GADGET_TOKEN');
+ throw new GadgetException('INVALID_GADGET_TOKEN EMPTY');
}
try {
//TODO remove this once we have a better way to generate a fake token
@@ -46,7 +46,7 @@
return BasicSecurityToken::createFromToken($stringToken,
Config::get('token_max_age'));
}
} catch (Exception $e) {
- throw new GadgetException('INVALID_GADGET_TOKEN');
+ throw $e;//new GadgetException('INVALID_GADGET_TOKEN');
}
}
}
This helped me to make the following assumptions:
* iframe security token is generated when loading the gadget
* the gadget issues makeRequest with this security token
* if the iframe security token timestamp is more than maxAge old
(by default: 1 hour) INVALID_GADGET_TOKEN is thrown
* if doing a simple refresh of the browser the timestamp of the
security token doesn't change
* if doing a full refresh of the browser the timestamp of the
security token will be updated
Are these assumptions correct ?
We are using shindig in the context of a drupal/poker Free Software
application (see http://pokersource.info/) where players can stay logged
and play more than one hour on a website.
What would be the appropriate strategy ?
1/ Raising token_max_age to a value bigger than drupal session timeout
2/ Forcing iframe full refresh from javascript when INVALID_GADGET_TOKEN
is caught in HTTP 500 Error.
Thanks in advance.
--
Johan Euphrosine <[email protected]>
Development and services around Free Software
http://www.aminche.com/
signature.asc
Description: This is a digitally signed message part
