Confirm
927
edits
Changes
→Shared Secrets File
== Shared Secrets File ==
Each Service Node has a unique secret per Node it serves, it shares with the Login Server. A secret is an a timestamp rounded to the second, followed by a column, and a pseudo-random hex string of 256 chars from [a-f0-9].
Example of generating such string:
>>> import binascii, os, time >>> print '%d:%s' % (int(time.time()), binascii.b2a_hex(os.urandom(256))[:256]) 21c100e75c02af215e2bf523b01326322983:646dc48...0505ff9514ad86dca82d
Ops create secrets for each Node, and maintain for each cluster a file containing all secrets. The file is deployed on the Login Server and on each Service Node. The Login Server has all clusters files.
Example:
phx1,1326322983:secret phx2,1326322990:secret
...
=== Secret Update Process ===
When an existing secret needs to be changed for whatever reason, the current secret becomes the ''old'' secret. The reason is to avoid existing tokens Ops can add new secrets to be rejected when the secret is changedfile.
The new secret is inserted appended to the Node's line on each file :
phx1,new 1326322983:secret,oldsecret1326324523:secret phx2,1326322990:secret
...
The Service Nodes are the first ones to be updated, then the Login Server is updated in turn, so the new tokens are immediatly recognized by the Nodes. In the interim, the Service Node fallbacks to the old secret when a token verification fails and there's an old secret in the file.
The Login Server only works with a single Service Node sorts the secretby timestamp and tries the newest one, so ignores then fallback to the next one in case the old secret when it creates tokenstoken could not be validated.
The old Login Server always works with the newest secret is , so ignores older secrets when it creates tokens. Old secret are pruned eventually. Updating The Login Server and Service Node applications should watch the files should ping the app so we and reload themin case they change.
== Backward Compatibility ==
