Since a few people had problems figuring out how security tokens work in and between Shindig and Partuza, I thought it might be useful to write up a quick post that details how this works.
So to start off, the security token is generated in Partuza in Application/Views/gadget/gadget.php :
-
$securityToken = BasicSecurityToken::createFromValues(isset($vars['person']['id']) ? $vars['person']['id'] : '0', // owner
-
$gadget['id'], // app id
-
PartuzaConfig::get('container'), // domain key, shindig will check for php/config/<domain>.php for container specific configuration
-
$gadget['mod_id']);// mod id
A bit of background: php-shindig expectes an encrypted and encoded security token, since this way you can use the cryptography to be sure that the owner and viewer ID's are not faked, a very important assumption if you don't want people to be able to spoof identities (and do naughty things like setting someone else's status update to 'i'm a big fan of poodles' (make up your own examples to get an idea of the true impact of this)).
However the out-of-the-box html samplecontainer (shindig/javascript/samplecontainer/*) uses plain text tokens, so there's support build in for this as well, but it should be turned off *as soon as possible* since it makes for a completely non-secure situation.
So Shindig does expect a "owner:viewer:appId:domain:url:modId" type token, but it can consume it in either plain text, or encrypted form.
What partuza does is generate an *encrypted* security token and it does so using the password phrases listed in partuza/html/config.php:
-
// Security token keys
-
'token_cipher_key' => 'INSECURE_DEFAULT_KEY',
-
'token_hmac_key' => 'INSECURE_DEFAULT_KEY',
The shindig receives the secure token, and decodes it with it's password phrases (shindig/php/config/container.php) :
-
// The encryption keys for encrypting the security token, and the expiration of it. Make sure these match the keys used in your container/site
-
'token_cipher_key' => 'INSECURE_DEFAULT_KEY',
-
'token_hmac_key' => 'INSECURE_DEFAULT_KEY',
Do note that these have to be the same on both ends, otherwise it won't be able to decode the token into anything sensible, and you'll get an error code returned.
After you have this working, make sure to disable the plain text security tokens, since that's a huge wide open security hazard waiting to happen, so change this to false (in shindig/php/config/container.php)
-
// Allow plain text security tokens, this is only here to allow the sample files to work. Disable on a production site
-
'allow_plaintext_token' => true,
Now the last thing that is interesting to know, is that all the classes in php-shindig that might be different between site specific implementations are completely configurable, and we provide basic examples (which are easily identified by their Basic*.php naming) which are production ready and actually see massive production usage too, but if you want to implement your own, so that you could for instance add custom fields to it, simply point the configuration to your own class, and off you go:
shindig/php/config/container.php:
-
'security_token_signer' => 'BasicSecurityTokenDecoder',
-
'security_token' => 'BasicSecurityToken',
That rounds up our security token tour for the day, if there's anything that I missed out on or something the shindig community can help you with, you can find us on the shindig-dev@incubator.apache.org mailing list.
[...] There’s a bit more information about how security tokens work and how to implement them in this blog post: http://www.chabotc.com/partuza/about-partuza-and-shindig-security-tokens/ [...]