Currently, the system uses two caches to manage the token strategy. The caches are authtokens and active. The authokens cache stores all valid authtokens. The key is the authtoken and the value associated with the key is the user's account data including scopes. The authtoken cache allows for a token to be authenticated in one operation. See lib/authtoken.js for details.
The second cache stores active tokens. The purpose of this cache is to pre-empt users from creating multiple tokens. If a user already has a valid token stored in the cache and tries to authenticate, we return the existing token rather than create a new one. The key in this cache is the username for the authenticated user. Values associated with the key are the users authtoken and account data. The active cache allows us to check if a user has an existing valid token in one operation.
What do you think about using two hapi caches versus a database table?
Perhaps this is not a use case the cache was designed for. If so, please share best use cases for hapi cache. Using two caches could be avoided by using a database table to manage tokens. When using a table, one could index the username and authtoken columns to perform queries on instead of having two caches. Chose to use hapi's caching because redis outperforms most DBs and hapi's caching support manages expired tokens which is a nice feature.
What do you think about using cryptiles to generate random token values?
Relevant files:
lib/tokencache.jsplugin registers the cache.lib/authtoken.jsplugin registers the auth-token-strategy. Validation of authentic tokens is performed here.lib/version.jsplugin registers the application's routes.lib/route-methods/authenticate.jscontains methods used on the/authenticateroute. Tokens are generated and stored in the cache here.System depends on:
Currently, the system uses two caches to manage the token strategy. The caches are
authtokensandactive. Theauthokenscache stores all valid authtokens. The key is theauthtokenand the value associated with the key is the user's account data including scopes. Theauthtokencache allows for a token to be authenticated in one operation. Seelib/authtoken.jsfor details.The second cache stores
activetokens. The purpose of this cache is to pre-empt users from creating multiple tokens. If a user already has a valid token stored in the cache and tries to authenticate, we return the existing token rather than create a new one. The key in this cache is theusernamefor the authenticated user. Values associated with the key are the usersauthtokenand account data. Theactivecache allows us to check if a user has an existing valid token in one operation.What do you think about using two hapi caches versus a database table? Perhaps this is not a use case the cache was designed for. If so, please share best use cases for hapi cache. Using two caches could be avoided by using a database table to manage tokens. When using a table, one could index the
usernameandauthtokencolumns to perform queries on instead of having two caches. Chose to use hapi's caching because redis outperforms most DBs and hapi's caching support manages expired tokens which is a nice feature.What do you think about using cryptiles to generate random token values?
Other thoughts or recommendations? Please share.