apigee-127 / volos

Key Node.js modules for building production-quality APIs

Status](https://coveralls.io/repos/github/apigee-127/volos/badge.svg?branch=master)](https://coveralls.io/github/apigee-127/volos?branch=master)

Apigee Volos

Volos is an open source Node.js solution for developing and deploying production-level APIs. Volos provides a way to leverage common features such as OAuth 2.0, Caching, and Quota Management into your APIs with maximum joy.

All modules are exposed with well-defined interfaces and full test suites such that, for example, changing between a memory-backed Cache or Quota implementation to a Redis-backed one requires only a simple configuration change. In addition, all modules also have the option to proxy to Apigee Edge.

Finally, all modules include Connect, Express, and Volos middleware for easy integration into http proxies and applications.

---

Quick start

Check out the training sample.

---

Usage

Apigee Proxy

All modules are capable of using Apigee Edge as a commercially supported, hardened and distributed backend implementation (though this is not required). If you intend to use the Apigee Edge implementations, you'll need to install an Apigee proxy into your Application on the Apigee Edge server. See Apigee proxy installation

Core Modules

The following modules are part of the core of Volos and are available for inclusion in your project via npm:

OAuth 2.0

OAuth 2.0 support with bearer tokens and all the standard grant types. Includes a raw API, plus middleware for Express and Argo.

Two implementations are supported:

• volos-oauth-redis: Uses Redis as a database for OAuth tokens and other data
• volos-oauth-apigee: Communicates with Apigee via API for all data storage

Quota

Support for "quotas" as implemented in many APIs -- count API calls by minute, hour, day, and week and reject them when they are exceeded.

Three implementations are supported:

• volos-quota-memory: Keeps quota buckets in memory
• volos-quota-redis: Keeps quota buckets in redis
• volos-quota-apigee: Communicates with Apigee via API to store quota values across servers

Cache

A simple cache module, supporting "put, "get," and "delete" of string keys and binary values.

Three implementations are supported:

• volos-cache-memory: Keeps cache in memory
• volos-cache-redis: Keeps cache in redis
• volos-cache-apigee: Uses Apigee cache (when running on Apigee)

Support Modules

volos-management-apigee

This is a small module that wraps the Apigee management API for creating developers, applications, and the like. It is deliberately separated from the runtime because these operations should not happen often and do not necessarily support high volume. This module is mainly used for testing.

volos-management-redis

This is the equivalent management module for Redis.

---

Development

If you're developing on this project, it is easiest to link all the various modules into your node_modules directory so they all run locally instead of pulling from npm. To do this, just run:

    npm install

and then:

    bin/link

Testing

Test scripts are written using "mocha." Install mocha if you haven't already like this:

    npm install -g mocha

To test Apigee providers:

1. Install the "proxy" module on an Apigee application. See the instructions here.
2. In the "testconfig" directory, copy "testconfig-apigee-sample.js" to "testconfig-apigee.js" and edit the values. You will need to specify the location of your proxy as well as the key and secret for the application.
3. Run mocha in each apigee/test directory you wish you test.

To test Redis providers:

1. Install and start a redis server.
2. In the "common" directory, copy "testconfig-redis-sample.js" to "testconfig-redis.js" and edit the values if necessary.
3. Run mocha in each redis/test in order to run the tests for that module.

Support

The support model for Volos is 'community support' only. This means that you can use publicly-available resources to solicit assistance from the Volos developer community. Apigee does not offer official support for this product.

Having Problems?

If you are having issues with Volos please do one or both of the following:

1. Open an issue in the GitHub issue tracker
2. Ask a question on Stack Overflow

We will do our best to help you resolve the issue as soon as possible.

volos's Issues

support streaming in cache middleware

JSON Web Tokens (JWT)

See: http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer

Should Apigee runtime provider require a client key for OAuth?

Code in question: https://github.com/apigee/volos/blob/master/oauth/providers/apigee/lib/apigeeruntime.js#L257

My thinking is that client credentials should be set by API consumers and client auth/authz should be delegated to Apigee by the runtime in Volos. Seems weird to require one set of client credentials to validate another.

Thoughts?

/cc @gbrail

in volos-swagger add the option to configure external 'beforeCreateToken' function

As can be seen here:
https://github.com/apigee-127/volos/blob/master/swagger/lib/auth-middleware.js#L179
the module provides an option to provide an external 'passwordCheck' function written by the user.
This function can be provided in the swagger.yaml as can be seen here:
https://github.com/apigee-127/a127-samples/blob/master/oauth-password-sample/api/swagger/swagger.yaml#L35

Please add the same option (external function configured in the swagger.yaml) for the 'beforeCreateToken' method as well. As you can see here:
https://github.com/apigee-127/volos/blob/master/oauth/common/lib/oauth.js#L59
the oauth module supports the option of customized external function.

Thanks,
Boris

The remaining reset time of quota module

Hello,

Is it possible to add an additional value in the callback result of quota.apply(). I think its useful in most restful API for the HTTP header X-Rate-Limit-Reset.

X-Rate-Limit-Reset: the remaining window before the rate limit resets in UTC epoch seconds

Best regards,
Kevin

Allow express session to use volos cache as a session store

See:
https://github.com/apigee/api-platform-samples/blob/master/sample-proxies/oauth-advanced/login-app/apiproxy/resources/node/lib/apigee-session-store.js

And:
https://github.com/apigee/api-platform-samples/blob/master/sample-proxies/oauth-advanced/login-app/apiproxy/resources/node/app.js

npm Version is out of sync and buggy

Just a hint:
The current versions of the volos modules in NPM are newer than master and they are partly buggy. For example underscore is missing as dependency in package.json for some of them.

Change apigee cache fallback message to be clearer

Currently, the fallback error says:

"Error: Apigee cache not available. Specify options.fallback to avoid error.”

Change to:

"Error: Apigee cache not available. Specify ‘fallback' option to use this cache outside of Apigee.”

volos-oauth-redis requires client_secret when using the password grant type

Hi,

As I understand the password credentials flow, the client_secret isn't required because this flow is usually used on mobile or web applications where the credentials can be extracted by a 3rd party\attacker.

As you can see here
https://github.com/apigee-127/volos/blob/master/oauth/redis/lib/redisruntime.js#L126
the clientSecret is required in order to use this flow.
But, when calling the createAndStoreToken function, the first action there is to check the clientSecret only if the grant type is different than 'authorization_code' and 'password', which seems to me like the valid check:
https://github.com/apigee-127/volos/blob/master/oauth/redis/lib/redisruntime.js#L356

It seems to me that the this.mgmt.getAppIdForCredentials check
https://github.com/apigee-127/volos/blob/master/oauth/redis/lib/redisruntime.js#L129
is redundant (and false) and need to be removed because createAndStoreToken already checks the existence of the app correctly based on the grant type.

I hope I'm not missing something :)

Thanks,
Boris

in volos-swagger missing username and password in the token path inside oauth_operations.yaml

Hi,

I'm using swagger-ui while exposing the access token outh2 token path.
When trying to call this method from within the swagger-ui I don't have the option of adding username and password as parameters because they aren't appears in the oauth2 operations spec here

Thanks,
Boris

OAuth Argo provider breaks routing flow for apps

In the Argo provider for OAuth, the extension is setting up a couple of routes and then adding a middleware for authentication. This surfaced undefined behavior in Argo, per argo/argo#39.

This has since been fixed. However, there are still bugs in the provider implementation. I'm currently investigating.

Defining two OAuth providers in Swagger may be problematic

If you define two Volos OAuth providers in Swagger, it appears that you could run into issues. Tests need to be written to ensure that this works 100% (especially path overrides) or we need to disallow multiple OAuth definitions in a Swagger document.

npm run cache

Hello,

I'm trying to run volos examples that integrate with Apigee, however npm run cache throws this error:

/samples/training/node_modules/volos-cache-apigee/lib/cache.js:80
  if (!cache) { throw new Error('Apigee cache not available. Specify options.f
                      ^
Error: Apigee cache not available. Specify options.fallback to avoid error.
    at new Cache (/volos/samples/training/node_modules/volos-cache-apigee/lib/cache.js:80:23)

What would the fallback option above be? I guess this option would be added to this object, correct?

Thanks,
Diego

volos-swagger - add support for redirection of oauth2 authentication requests to remote server

Hi,

In addition to #53, in a microservices architecture where one server responsible to the oauth2 and all the others are business logic only, there is need to redirect all authentication requests (authorize, token, invalidate and refresh) to one place.

As I understand there are 2 options for that (I'm really not an expert):

1. Add proxy before the servers which redirects all the authentication requests to the relevant server.
2. Make all the servers accept and understand this requests but redirect them to the relevant server.

To implement option 2 with volos there is need to configure the relevant paths (authorize, token, invalidate and refresh) and let volos to redirect them to the right place.
If I understand correctly, the authorize and token paths can be implemented "out of the box" if volos will support authorizationUrl & tokenUrl. Not sure about other methods (invalidate and refresh).

I'll be glad to hear your thoughts :)

Thanks,
Boris

publish scope support in volos to npm

first of all congratulations for this awesome library... i noticed support has been hadded for scopes in volos but the changes are yet to be published to npm.. When are you planning to do so? many thanks for all this great stuff! keep up the good work!

potential security issue with the new API Key functionality

Hey,

This scenario describes a volos based server:

The API Key expected to be some client Id ->
Client Id is a public information ->
Can be retrieved from any server that exposes any of the authentication flows (because they require the existence of a client) ->
If in addition this server authenticate some requests with an api key (for example in order to perform operations through the swagger UI interface), an attacker can use any public client Id as API key in order to execute authenticated operations without suppling any personal data and without receiving any explicit API key.

Am I missing something ? :)

volos-oauth-redis related question: How to protect an api from deleted account valid tokens?

I'm not sure that this is the right place but I'll try anyway :)

The scenario:

1. User asks for a token (password flow).
2. User deactivates\deletes its account.
3. The token is still valid (I know that its possible to invalidate token but there is another scenario where user generates tokens from 2 different clients (browser\mobile) or 2 different browsers -> receives two valid tokens -> impossible to invalidate 2 different token so one is still valid).

How should I protect my API from a valid token that it's owner isn't relevant anymore?

1. I don't see a way where its possible to invalidate all token related to some user (ever if the user's id stored in the token's attributes).
2. Is the only way is to store user's Id inside the token attributes, verify the token, get the user's Id and check that the user is still active for every operation? Its a big overhead for such an end case.
3. In a situation where all user's related data is being deleted as well there is no problem (the api response will be empty), but there are cases where this data isn't being deleted.

Thanks,
Boris

cache.get callback returns undefined always

hi there,
I'm trying a volos-cache-memory to verify whether a key exists or not (see code below). However, the callback function error parameter always returns undefined, regardless the key exists or not. Am I missing anything? Thanks!

var cm = require('volos-cache-memory');
var cache = cm.create('name', { ttl: 1000 }); // specifies default ttl as 1000 ms
cache.set('key', 'value');
cache.get('key', function(error, cachedValue){
    console.log(cachedValue.toString());
    console.log(error)
});
//cache.set('invalidKey', 'hola value');
cache.get('invalidKey', function(error, cachedValue){
    console.log(error); //returns undefined regardless cache key is defined or not
    //console.log(cachedValue.toString())
});

Add db option to cache and oauth redis providers

See also: #31

app-middleware in volos-swagger crashes when operation of some route not defined

if trying to make http call on undefined operation (some route exposes only get method and trying to make a post call on that route) so the middleware crashes because of an access to a key of undefined object (the operation is undefined):
https://github.com/apigee-127/volos/blob/master/swagger/lib/app-middleware.js#L42

to solve that just replace the next line:
https://github.com/apigee-127/volos/blob/master/swagger/lib/app-middleware.js#L39
with this one
if (!req.swagger || !req.swagger.operation) { return next(); }

registering cache middleware redundantly at global & operation level hangs

Not able to create a fallback cache when configuring a volos-cache-apigee in swagger

When running with a RemoteProxy using a127 with a Apigee cache configured in swagger, I was getting errors when it tried to create the fallback cache. The error I got was that options.fallback did not have a create function.

I just submitted a pull request that seems to fix the problem. I hope this helps.
pull request: #70

I think this might also address an the apigee forum quesiton:
http://community.apigee.com/questions/661/correct-use-of-volos-cache-apigee.html

The questioner was asking about the fallback configuration.

...Ed

Is the client secret has to be required in the invalidateToken operation (volos-oauth)?

I'm using the password flow in order to generate tokens (with the connect middle-wares) and login users to my web app. This flow doesn't require the client secret. In order to logout users I want to do the same only with the invalidate middleware, but the invalidateToken requires the client secret.

Is the client secret has to be required in the invalidateToken operation ? Its not something that should be exposed in the client side.

Thanks,
Boris

question: Any chance of creating plugin integration to hapijs in addition to express, connect and argos?

I see you have integration of volos using express, connect and argos middleware, it would be great if there were also hapijs plugins for volos.

I am fairly new to node, I've used express but I am playing with the idea of trying out volos along with trying out hapijs for a simple proof of concept.

Thanks!

Cache data not captured in AX when a127 proxy is deployed on Edge

See the following Community thread for details:

https://community.apigee.com/questions/1797/the-cache-performance-analytics-says-no-data-to-sh.html#answer-1885

wrong expiryTime in the callback of quota.redis

Hello,

Sincerely appreciate for your update for #14 at first.

However, I found a bug in the implementation for volos-quota-redis module.
The expiryTime in the callback will be always calculated whenever calling the quota.apply. As a result, the expiryTime is always changed even it has not been expired. I think it should be only calculated once when the key is stored in the redis.

I tried to write some modification for that.
https://github.com/apigee/volos/blob/master/quota/redis/lib/redisquota.js#L66

self.client.ttl(options.identifier, function(err, ttl) {
  if (err) { return cb(err, null); }
  var exp = ttl * 1000 + now;
  if (count === options.weight) {
    exp = self.calculateExpiration(now);
    ttl = (exp / 1000) >> 0;
    self.client.expireat(options.identifier, ttl);
  }

  var allow = options.allow || self.options.allow;

  var result = {
    allowed: allow,
    used: count,
    isAllowed: (count <= allow),
    expiryTime: exp
  };
  cb(undefined, result);
});

In addition, calculating the expireTime by adding ttl with now is not so accurate I think. As the HTTP recommends,

X-Rate-Limit-Reset: the remaining window before the rate limit resets in UTC epoch seconds

This HTTP header means the remaining seconds before reset. Therefore, just returning the ttl is better, isn't it?
What's your opinion about that?

Bg,
Kevin

add custom 'afterTokenVerified' function (similar to beforeCreateToken) after succesfull verification in volos-oauth

Hi,

Add user defined function to the token verification flow that receives the verification result and the callback. This function will be able to return customized data that will be attached to the token attribute instead of the current token's verification data.
More custom way is to pass the req object to this function in order to be able to attach user's defined attributes to the req object but it requires some fundamental changes in the implementation.

Adding this kind of operation will make the authentication process more customizable from user perspective and this support will be similar to passport's serialize\deserialize methods (e.g. in beforeCreateToken we can store user's id in attributes and in afterTokenVerified it will be possible to get the user from the database and attach to the request).

To support this it requires:

1. Be able to add afterTokenVerified to x-a127-services:oauth2:options in swagger.yaml.
2. Duplicate this check only with afterTokenVerified attribute.
3. Duplicate this only with afterTokenVerified attribute.
4. Call the method instead of this callback
5. If no function supplied, the current behavior is the default.

Thanks,
Boris

add "updateToken[Scopes]" method to the volos-oauth api

Hey,

I'm using volos-oauth-redis as my oauth2 provider and using the password flow in order to authenticate users and generate tokens for them on a web app. In addition, I'm using the scope mechanism for authorization.

I have the following scenario:
In my application users can change their status (e.g. in ebay, user becomes a seller) and by that be able to make operations that require more permissions than their token allows.
Now, in the current volos-oauth's api, in order to "adjust" the token to the new status I have to 2 options:

1. Invalidate the used token, generate a new one with the relevant scopes and return it to the client. In order to do that I have to ask the user for his details and I'm trying to avoid it. It seems to me that in this case, returning new token on a "standard" api call just "pollutes" the api and its not the right solution (I know I can make 2 api calls, one for status change and one for token change, but still, it seems wrong to me that its not atomic and not internal). And this solution won't fix the problem that a user logged in from 2 different devices and asking for status change from one of them.
2. Same as 1, but generate a new token with the client_credentials flow without the need of user details. Seems a little bit awkward to me that token generated by the password flow has to be replaced by a token generated by a different flow.

It seems to me that the most appropriate solution in this scenario is to be able to update the token's internal details (scopes) without the need of asking for additional details and without the need of invalidating the token.

Does it seems reasonable? Am I missing something? Any security issues with that? :)

Thanks,
Boris

Update security handling for swagger-tools change

See: apigee-127/swagger-tools#117

Optionally pass HTTP request to oauth SPI

The Apigee OAuth SPI supports a mode in which it will automatically update analytics inside the Apigee platform, but it needs the original HTTP "request" object passed to it in order to do that.

I don't believe that volos-oauth-common does this today, and we'll need to add it if we want to get good analytics on the data passing through the proxy.

question: How can I get oauth info from within a message handler?

I have played with the oauth capabilities in volos (both the redis an apigee oauth handlers) but I can't seem to figure out how to get oauth info when I am in a route handler for a message.

Is there a way to get info like the access token, client id, application, etc.?

Thanks!
...Ed

P.S. Let me know if you'd rather I go somewhere else to ask questions. I thought asking here might help others who might have the same question.

Invalid value in array api.environments

a127 version: 0.12.2

Scenario: I execute 'a127 account create accountname' and choose to create a RemoteProxy service targeting an apigee on-premises that does not have any environment called 'prod'.

Part of error message:
Error: {
"code" : "keymanagement.service.InvalidEnvironment",
"message" : "Invalid environment prod",
"contexts" : [ ]
}

Note that I haven't specified anywhere that a127 should use environment 'prod'.

Dirty workaround by hard-coding the environment to use:
In file apigeemgmt.js, replace line 168 with this line:
environments: [ 'test' ],

remove spikearrest-apigee reference in README

The README refers to volos-spikearrest-apigee, but that module hasn't been implemented.

Put core modules in seperate git repositories

Hi,

I don't see why all these modules are in a single git repository, but separate on npm.

For example volos-quota-redis has its own npm module but not its own git repo. This is very confusing and makes it more messy to contribute.
It also seems to cause some bugs that would have been caught instantly if the modules where separate. For example volos-quota-redis is missing underscore in its package.json, which simply makes it unusable without manually installing underscore. (#16)

Please consider splitting into separate git repositories.

volos-swagger - add support to verifyToken in remote address

Hi,

In addition to #52, in a microservices architecture where one server responsible to the oauth2 and all the others are business logic only, there is need to verify the authenticated requests in a remote server. So there is need to tell swagger.yaml the url to verity the token.

I'm not sure how to configure this because the check if to verify in a remote address should be here (I think so, not sure) but this lines are in use only when the oauth2 service is defined inside swagger.yaml inside x-a127-service, but, server with business logic only won't contain any of the volos-oauth-provider.

It seems like the best place is to add something like "verifyUrl" to the securitySchemeObject but maybe I'm missing something because I'm not expert in oauth2 authentication flows.

I'll be glad to hear your thoughts :)

Thanks,
Boris

in volos-swagger the spec of the token endpoint expects the scope param to be in the query but the volos-oauth-common connect middleware ignores it

Hi,

As you can see here:
https://github.com/apigee-127/volos/blob/master/swagger/spec/oauth_operations.yaml#L96
the scope param expected to be in the query.

In addition, the volos-swagger module adds dynamically the token endpoints paths defined in the swagger document:

x-a127-services:
  oauth2:
    provider: volos-oauth-redis
    ...
    tokenPaths:  # These will be added to your paths section for you
        token: /accesstoken
        invalidate: /invalidate

and adds a middleware to take care of that:
https://github.com/apigee-127/volos/blob/master/swagger/lib/controllers/volos-oauth.js#L39

Now, the middleware defined in the volos-oauth-common module:
https://github.com/apigee-127/volos/blob/master/oauth/common/lib/oauth-connect.js#L63
and as you can see there is no reference to the scope param which in the query. As a workaround I'm passing it in the body but it should be as expected in the spec (defined in volos-swagger) and should be extracted from the query and added to the body here:
https://github.com/apigee-127/volos/blob/master/oauth/common/lib/oauth-connect.js#L68

Thanks,
Boris

support basic and api-key authentication flows

Hi,

Because of swagger spec support in this authentication modes, do you have any plans to add support for them in your volos, swagger-tools, volos-swagger modules?

Thanks,
Boris

allow return null from cache function to signal not to cache

Missing dependency 'underscore'

I added volos-oauth-redis and volos-oauth-apigee to my package.json and it downloaded these dependencies. However, 'underscore' is a transitive requirement for these packages and it's included with their dependencies.

module.js:340
    throw err;
          ^
Error: Cannot find module 'underscore'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/Users/swilson/code/nodeapp/node_modules/volos-oauth-redis/node_modules/volos-oauth-common/lib/oauth.js:26:9)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)

Adding underscore to my application's package.json resolved the problem, but adding 'underscore' to the deps for volos-oauth-common and allowing it to be resolved transitively is a more complete solution.

Support no ttl default set for volos cache

Hello,

As is known to us, redis cache is able to act as a LRU cache when no ttl is set. This means the key-value pair will be cached based on LRU strategy and they will not be invalidated even the ttl is expired.

However, the ttl of volos cache interface is set by default value 300 ms. For the memory cache, it has not such configuration for sure. Is it possible to extend volos cache for supporting this feature as well?

Bg,
Kevin

add verifyToken to volos-swagger

Hi,

In order to implement an oauth2 server only (it's only purpose is to generate and verify tokens) based on volos-ouath the missing part is to expose the verifyToken operation

I guess that this method will expect the token and the required scopes to be inside the request body.

The use case for that is microservices architecture where one server is responsible for the token generation and verification and all the others are business logic only.

To support this it requires:

1. Add one more path (verify) to x-a127-services:oauth2:options:tokenPaths in swagger.yaml.
2. Add the specification of the method here.
3. add a controller here.
4. change the implementation of the authenticate method or add a new one that expects the parameters to be in request's body.

Thanks,
Boris

TTL for cache

Hello,

I read the doc and searched in the source code of volos cache stuff. The default of ttl for each cache is 300ms as default. Is there anyway to define a cache with permanent key-value pair in redis or in memory? I think redis support this for sure.

Meanwhile, I think the cache API still miss something like touch cache for updating maxAge.

Best regards,
Kevin

An Invalid API Key should create an error with a 403 status and a proper message ...

I created a app with a127 that has a method that has security that validates the apiKey.

It all works properly by stopping access if the apikey passed in does not match the apikey for the product. The problem I'm having is that the error returned is a 500 and the message is blank.

When I debugged into it, it looks like the makeError function in /volos-oauth-common/lib/oauth.js is not handling the case where the apikey is not valid, instead it drops to the default in a switch that checks the code and sets the statusCode to 500.

It would also be helpful if it set the message to something that indicates that the APIKEY is invalid..

What get passed to the makeError function is as follows when the apikey provided is invalid:
code = oauth.v2.InvalidApiKey
message = undefined
errProps = undefined

Please let me know if you need any other information about this.

Thanks,
...Ed

quota apply w/ weight == 0 actually applies 1

1. Can all providers support actually processing weight == 0? Do we want to?
2. The actual use case was just wanting to retrieve quota statistics. Can this be exposed directly?

Question/ Potential Enhancement Aaout Volos Oauth

Hi,

I like the approach to factor out common parts for the auth and other API aspects and still support different middlewares very much!

The OAuth Module also supports a function to verify an API Key (which is usually permanent). What I miss is the counterpart to generate such a key.
There is OAuth.generateToken but this is obviously to process standard OAuth flows.
Ans as you say, the API key stuff is not standardized (but still essential), so how to generated one?

greets

Delete keys matching a pattern using Redis cache

Hello,

Generally I found that deleting keys in volos redis cache is implemented like the following.

1. Search all the keys starts with cache name in the redis by using keys interface of node-redis.
2. Delete all found keys parallel.

Is it possible to extend volos cache for deleting keys matching a pattern?

I need to cache different resource for our use, but it's not a better idea that dynamically create cache with different cache name for each resource. Please understand.

Bg,
Kevin

error in middleware using a cache with encoding

Using a cache like this:
Cache.create('response', { ttl: 60000, encoding: 'utf8' }),

Will result in:
has no method 'readUInt8'
at Object.exports.setFromCache (/Users/dino/dev/node/argo1/node_modules/volos-cache-memory/node_modules/volos-cache-common/lib/cache-encoder.js:76:27)

Should document no encoding restriction and fail fast if Cache has encoding set.

per-route cache broken on Argo

ensure caching middleware works with binary data

When using volos Analytics, a record should get recorded with "best info available" regardless of status of Quota or OAuth

Analytics in Volos (running standalone, outside Edge) works like a regular Volos policy step. If I insert the analytics step before the token validation, then the AX record does not include identity or token status. If I insert the AX step after the token validation step, then the AX record does include the token status, but only if the token is valid. If the token validation has thrown an exception, then the AX step doesn't run.

Similarly, suppose I use Volos for OAuth, quota, and analytics. If I insert the AX tep after oauth and quota, then the AX record gets recorded ONLY if both oauth and quota pass. If either rejects, then there is no AX record. Likewise for the cache policy; if the AX step is placed after the volos cache step, and if the request is satisfied from cache, then we get no AX record.

This makes it a non-starter for people who want to use nodejs + volos as the basis for an agent model, for managing internal-to-internal API invocations, with the Apigee Edge cloud service.