apigee-internal / microgateway Goto Github PK

Apigee is rolling out a new feature allowing org admins to enable 2-Factor Auth for the Management API. The microgateway needs to support this for the edgemicro-auth deployment and key/secret storage.

Reference: https://community.apigee.com/articles/26487/two-factor-authentication-using-one-time-passwords.html

Edge Microgateway doesn't execute the plugins for the request with invalid paths. Few plugins should be executed no matter the type of request. For instance, we have written a custom plugin which processes the X-Forwarded-For header of the request to get the actual client IP but that plugin never executes for the request paths that are not configured in edgemicro_* proxies.

MGW version: 2.5.8 running in Docker

Reload completed
Error [ERR_IPC_CHANNEL_CLOSED]: Channel closed
    at ChildProcess.target.send (internal/child_process.js:606:16)
    at Worker.send (internal/cluster/worker.js:40:28)
    at disconnectAndShutdownWorker (/usr/local/lib/node_modules/edgemicro/cli/lib/reload-cluster.js:148:16)
    at EventEmitter.replaceAndTerminateWorker (/usr/local/lib/node_modules/edgemicro/cli/lib/reload-cluster.js:121:5)
    at EventEmitter.emit (events.js:159:13)
    at emit (/usr/local/lib/node_modules/edgemicro/cli/lib/reload-cluster.js:56:15)
    at EventEmitter.emitWorkerDisconnect (/usr/local/lib/node_modules/edgemicro/cli/lib/reload-cluster.js:169:5)
    at EventEmitter.emit (events.js:159:13)
    at ChildProcess.worker.process.once (internal/cluster/master.js:207:13)
    at Object.onceWrapper (events.js:254:19)
    at ChildProcess.emit (events.js:159:13)
    at finish (internal/child_process.js:775:14)
    at process._tickCallback (internal/process/next_tick.js:150:11)
  microgateway Caught Unhandled Exception: +633ms

Exception seems to occur because of worker.send in cli/lib/cluster-reload.js:150.
try { worker.send({cmd: 'disconnect'}); worker.disconnect(); } catch (e) { }

To make the exception visible we changed cli/lib/gateway.js:136 to include an actual error:
process.on('uncaughtException', (err) => {

Not sure how to fix the actual exception though.

Every time I call my edgemicro_* proxy with an API key, Edge Microgateway calls (POST request) the edgemicro-auth proxy to verify the API key. This request returns a JWT token, that's not used to validate subsequent API calls. We could use the JWT to verify the API key for future calls till expiry.

either let master be the only logger or use bunyan or winston

I see performance degradation when doing streaming through microgateway. The testing was done using artillery and using files ranging from size 100kiB to 100miB. The results are a comparison between apache and MG. On the logs I can also multiple restarts on MG.

To replicate the testing please see here

see explanation here

all scenarios completed
Complete report @ 2016-10-26T19:52:24.016Z
  Scenarios launched: 75
  Scenarios completed: 33
  Number of requests made: 853
  RPS: 2.22
  Request latency:
    min: 1.5
    max: 15649.9
    median: 21.6
    p95: 10018.8
    p99: 10304.8
  Scenario duration:
    min: 50935.2
    max: 116087.1
    median: 75387.9
    p95: 109780.1
    p99: NaN
  Codes:
    200: 687
    502: 123
    503: 43
  Errors:
    ECONNRESET: 42

=========  APACHE ======
all scenarios completed
Complete report @ 2016-10-26T20:00:08.362Z
  Scenarios launched: 75
  Scenarios completed: 67
  Number of requests made: 1160
  RPS: 3.45
  Request latency:
    min: 0.6
    max: 625.7
    median: 1.5
    p95: 90.8
    p99: 324.6
  Scenario duration:
    min: 41772
    max: 43868.8
    median: 42702.7
    p95: 43649.7
    p99: 43846.2
  Codes:
    200: 1160
  Errors:
    ECONNRESET: 8```

Error during first time setup.

$ edgemicro configure  -o rhezas -u [email protected] -p XXXXX -e test -d
current nodejs version is v8.9.1
current edgemicro version is 2.5.8
file doesn't exist, setting up
listdeployments: {"organization":"rhezas","environment":"test","baseuri":"https://api.enterprise.apigee.com","debug":true,"username":"[email protected]","password":{},"asynclimit":4}
Going to invoke "https://api.enterprise.apigee.com/v1/o/rhezas/e/test/deployments"
List of deployed APIs: {"aPIProxy":[{"name":"Pet","revision":[{"configuration":{"basePath":"/","steps":[]},"name":"1","server":[{"status":"deployed","type":["message-processor"],"uUID":"8d311ffa-c742-42ca-8707-3024c4309555"},{"status":"deployed","type":["message-processor"],"uUID":"c8d88d3b-b847-4c9e-a095-d69c3e126b0b"},{"status":"deployed","type":["router"],"uUID":"128875b4-2e2c-4803-ab44-ef03c2b27145"},{"status":"deployed","type":["router"],"uUID":"d1947fa3-0689-47b5-abef-d70e6e19e815"},{"status":"deployed","type":["router"],"uUID":"df2fbeec-b028-4d3c-bb96-a827b235166e"}],"state":"deployed"}]}],"name":"test","organization":"rhezas"}
All done
Give me a minute or two... this can take a while...
deployproxy: {"organization":"rhezas","environments":"test","baseuri":"https://api.enterprise.apigee.com","debug":true,"verbose":true,"api":"edgemicro-auth","directory":"/Users/angel/.edgemicro/tmp-668296YIxw9wBqh24","virtualhosts":"default,secure","username":"[email protected]","password":{},"asynclimit":4}
Resolve NPM modules = false
Going to create revision NaN of API edgemicro-auth
Using /Users/angel/.edgemicro/tmp-668296YIxw9wBqh24/apiproxy/edgemicro-auth.xml as the root file
Calling https://api.enterprise.apigee.com/v1/o/rhezas/apis?action=import&validate=false&name=edgemicro-auth
Creating revision NaN of API edgemicro-auth
Uploading java resource micro-gateway-products-javacallout-2.0.0.jar
Uploading jsc resource generate-verify-jwt.js
Uploading jsc resource send-public-key.js
Uploading jsc resource set-jwt-variables.js
Error: Error uploading resource: 400
    at handleUploadResult (/Users/angel/.nvm/versions/node/v8.9.1/lib/node_modules/edgemicro/node_modules/apigeetool/lib/commands/deployproxy.js:342:14)
    at Request._callback (/Users/angel/.nvm/versions/node/v8.9.1/lib/node_modules/edgemicro/node_modules/apigeetool/lib/commands/deployproxy.js:325:9)
    at Request.self.callback (/Users/angel/.nvm/versions/node/v8.9.1/lib/node_modules/edgemicro/node_modules/request/request.js:186:22)
    at emitTwo (events.js:126:13)
    at Request.emit (events.js:214:7)
    at Request.<anonymous> (/Users/angel/.nvm/versions/node/v8.9.1/lib/node_modules/edgemicro/node_modules/request/request.js:1163:10)
    at emitOne (events.js:116:13)
    at Request.emit (events.js:211:7)
    at IncomingMessage.<anonymous> (/Users/angel/.nvm/versions/node/v8.9.1/lib/node_modules/edgemicro/node_modules/request/request.js:1085:12)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:111:20)
    at IncomingMessage.emit (events.js:208:7)
    at endReadableNT (_stream_readable.js:1056:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)

Something like below cannot be done

vhosts:
  myvhost:
    vhost: "*"

Currently just the string match of Host is happening. Hence above vhost config will require something like bellow to succeed

curl -H 'Host: *' https://microservicedns.com/edge/api

Ideally I should be able to do as follow

curl https://microservicedns.com/edge/api

Running edgemicro configure multiple times leads to the following error:

creating vault
{ [Error: cannot POST https://api.e2e.apigee.net/v1/organizations/radical-new/environments/prod/keyvaluemaps (409)]
  text:
   { code: 'keyvaluemap.service.keyvaluemap_already_exist',
     message: 'KeyValueMap microgateway already exists',
     contexts: [] } }

The configure command should continue with the rest of the configuration if the KVM already exists so users can retry the command in case it fails midway

Steps

$ git clone [email protected]:apigee-internal/microgateway.git
$ cd microgateway
$ npm install
$ npm ls

Expected Results

$ npm ls
[email protected] C:\Users\kowalskif\Desktop\GIT\microgateway
+-- [email protected] invalid
| +-- [email protected] deduped
| +-- [email protected] deduped
| +-- [email protected] extraneous
| +-- [email protected] extraneous
| +-- [email protected] extraneous
[...]
|   `-- [email protected]
+-- [email protected]
| `-- [email protected] deduped
+-- [email protected]
| +-- [email protected] deduped
| `-- [email protected] deduped
+-- [email protected]
| `-- [email protected] deduped
+-- [email protected]
| `-- [email protected]
+-- [email protected]
`-- [email protected]
  +-- [email protected]
  `-- [email protected]
    `-- [email protected]

Actual results

$ npm ls
[email protected] C:\Users\kowalskif\Desktop\GIT\microgateway
+-- [email protected] invalid
| +-- [email protected] deduped
[...]
npm ERR! invalid: [email protected] C:\Users\kowalskif\Desktop\GIT\microgateway\node_modules\apigeetool
npm ERR! extraneous: [email protected] C:\Users\kowalskif\Desktop\GIT\microgateway\node_modules\apigeetool\node_modules\tmp
npm ERR! extraneous: [email protected] C:\Users\kowalskif\Desktop\GIT\microgateway\node_modules\cli-table
npm ERR! extraneous: [email protected] C:\Users\kowalskif\Desktop\GIT\microgateway\node_modules\mustache
npm ERR! extraneous: [email protected] C:\Users\kowalskif\Desktop\GIT\microgateway\node_modules\netrc
npm ERR! extraneous: [email protected] C:\Users\kowalskif\Desktop\GIT\microgateway\node_modules\node-unzip-2
npm ERR! extraneous: [email protected] C:\Users\kowalskif\Desktop\GIT\microgateway\node_modules\node-zip
npm ERR! extraneous: [email protected] C:\Users\kowalskif\Desktop\GIT\microgateway\node_modules\q
npm ERR! extraneous: [email protected] C:\Users\kowalskif\Desktop\GIT\microgateway\node_modules\read
npm ERR! extraneous: [email protected] C:\Users\kowalskif\Desktop\GIT\microgateway\node_modules\underscore

The KVM api used by Edgemicro only works for CPS works. Thus, this will not work with private cloud as well as many public cloud orgs.

Trying to install the latest stable (pre-beta) edgemicro leads to a missing portastic dependency.

$ sudo npm install -g [email protected]
[sudo] password for kowalskif: 
npm WARN engine [email protected]: wanted: {"node":">=5.0.0 <6.0.0"} (current: {"node":"4.4.3","npm":"2.15.1"})

> [email protected] install /usr/local/node-v4.4.3-linux-x64/lib/node_modules/edgemicro/node_modules/dtrace-provider
> node scripts/install.js

/usr/local/node-v4.4.3-linux-x64/bin/edgemicro -> /usr/local/node-v4.4.3-linux-x64/lib/node_modules/edgemicro/cli/edgemicro
[email protected] /usr/local/node-v4.4.3-linux-x64/lib/node_modules/edgemicro
[...]
├── [email protected] ([email protected])
└── [email protected] ([email protected], [email protected])

Then trying to get the help message leads to an error:

$ edgemicro --help
current nodejs version is v4.4.3
module.js:327
    throw err;
    ^

Error: Cannot find module 'portastic'
    at Function.Module._resolveFilename (module.js:325:15)
    at Function.Module._load (module.js:276:25)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (/usr/local/node-v4.4.3-linux-x64/lib/node_modules/edgemicro/cli/cmd.js:11:17)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)

When you do an "edgemicro reload" the "success" message is misspelled:

Reload Completed Succesfully

Using Apigee Edgemicro version 2.3.3 (latest release at this time), If I call an API proxy that exists in Apigee Cloud but this API proxy has an unavailable target endpoint, NONE of the "onresponse hooks" are called and the onerror_request is called.

However, in onerror_request: function(req, res, err, next) hook, the err parameter comes with NULL value, therefore its not possible to handle the error. This was previously discussed in the community forums, onerror_request and onerror_response hooks in custom plugins to handle errors .

Ex.: If I call:

curl -v http://localhost:8000/ping

where /ping as a unavailable target endpoint.

and in my plug-in, simply get the err parameter and print out:

onerror_request: function(req, res, err, next) {
  debug('plugin onerror_request ' + err);
  next();
}

i got the response in the EMG logs:

plugin:custom-test plugin onerror_request null

Thanks!

Could not get edgemicro private configure to work with a https runtimeUrl :

edgemicro sending +0ms {"key":"3887e977e9c18273f56506edad3e4cdd843bb25421ac7dee8eeb6b67b729069c","secret":"d461ca996909731a3bf3d4fe5d4db40f99ed3758748180e1f2489f4d7ca015e5"} to https://radical-new-prod.e2e.apigee.net/edgemicro/credential/organization/radical-new/environment/prod
{ [Error: self signed certificate] code: 'DEPTH_ZERO_SELF_SIGNED_CERT' }

While this works if you switch the -r flag to use http instead of https, it sends over the key and secret over http which does not sound ideal :

  edgemicro sending +0ms {"key":"dacee33a7d052c24c0497646ec32d30e1b9a3e20412b6b58ed5906273e1d3f06","secret":"6122b34d65ec63b2b6802b1ca3d3098129780df962b7a1210583a9a80bb185b7"} to http://radical-new-prod.e2e.apigee.net/edgemicro/credential/organization/radical-new/environment/prod

./edgemicro start should first look for following environment variables:

EDGEMICRO_ORG
EDGEMICRO_ENV
EDGEMICRO_KEY
EDGEMICRO_SECRET

Provide a flag to disable it.

I noticed that a new option -c or --configDir #86 was added to the 2.3.3 beta which is something we where looking for but it's missing for the Private Cloud configure. Are there plans to add this to the private configure?

./node_modules/edgemicro/cli/edgemicro private configure
current nodejs version is v7.5.0
current edgemicro version is 2.3.3-beta
username is required

Usage: configure [options]
Automated, one-time setup of edgemicro with Apigee Private Cloud
Options:

-h, --help                          output usage information
-o, --org <org>                     the organization
-r, --runtime-url <runtimeUrl>      the URL of the runtime server
-m, --mgmt-url <mgmtUrl>            the URL of the management server
-e, --env <env>                     the environment
-u, --username <user>               username of the organization admin
-p, --password <password>           password of the organization admin
-v, --virtual-hosts <virtualHosts>  comma separated virtual hosts to deploy with

The privateKey is stored in cleartext KVM. We should use encrypted KVM whenever possible.

--port option does not work in v2.2.2-beta. Child instances use port in config file.

We are seeing an error in version 2.4.6 and the latest beta when running the following configure command with the option -v to specify a virtualhost name. In our case our secure virtual host is named default. This seems to be ignoring the -v option.

Please note this does work in prior versions that I've used such as 2.3.5 or below. Also worth mentioning we're running on-prem so using the "private configure".

Command
edgemicro private configure -u "[email protected]" -o myorg -e test -r https://apis.somedomain.com -m https://edgemgmt-api.somedomain.com -v default

Error
current nodejs version is v8.3.0
current edgemicro version is 2.4.6
password:
delete cache config
deleted /Users/n0054122/.edgemicro/internal-sandbox-config.yaml
init config
file doesn't exist, setting up
configuring edgemicro internal proxy
deploying edgemicro internal proxy
deploying edgemicro-auth app
Give me a minute or two... this can take a while...
Error: Invalid virtual host reference secure. Context Revision:1;APIProxy:edgemicro-auth;Organization:internal;Environment:sandbox
at Request._callback (/usr/local/lib/node_modules/edgemicro/node_modules/apigeetool/lib/commands/deployproxy.js:655:12)
at Request.self.callback (/usr/local/lib/node_modules/edgemicro/node_modules/request/request.js:188:22)
at emitTwo (events.js:125:13)
at Request.emit (events.js:213:7)
at Request. (/usr/local/lib/node_modules/edgemicro/node_modules/request/request.js:1171:10)
at emitOne (events.js:115:13)
at Request.emit (events.js:210:7)
at IncomingMessage. (/usr/local/lib/node_modules/edgemicro/node_modules/request/request.js:1091:12)
at Object.onceWrapper (events.js:314:30)
at emitNone (events.js:110:20)`

IF cached config is not present then it should throw error.

which means the option should be -i, --ignorecachedconfig should be -c, --cachedconfig

Logging isn't working properly for two cases:

• Stdout logging is happening with console logs instead of actually logging.
• File logging isn't happening at all.

I have done some really cool stuff deploying the Microgateway as a sidecar container in a Kubernetes pod along with a cool way to do dynamic configurations. I think it would provide value to contribute documentation around this as I image there are many other people looking to use the MG with Kubernetes.

Would you see value in a contribution like this and if so how should I go about it.

Problem

Unlike Edge Cloud "policies", it is not possible to choose which chain of plugin (with their respective configurations) is associated with which API proxy under the edgemicro_* pattern. This is unlike Edge-Cloud, which allows to define a completely customized set of Policies, per API proxy.

This is a very severe limitation of the EMG hybrid model implementation.

Suggestion

EMG should give the flexibility of defining a per-API proxy list of plugins & associated configuration. We propose the following schema, extending the list of active proxies introduced in EMG 2.3.1.

We suggest the following configuration structure, where the sequence of plugins is defined per API proxy, and a for each pugin, an optional per-plugin configuration override:

  proxies:
    edgemicro_foo:
      # api-proxy specific sequence of plugins
      sequence:
        - spikearrest: true
        - quota: true
        - myplugin:
           # plugin-specific config override
           my-config-key: 123
           my-config-struct:
             foo: my-string
             foo: my-other-string
    edgemicro_bar:
      sequence:
        - spikearrest: true
        - myplugin-other: true

As discussed in a community post, it would be good to have the possibility to secure the connection between the microgateway and Edge Cloud via a 2 way TLS.
This would allow only the microgateways having the expected client certificate to be able to perform the calls to Edge Cloud to retrieve the public key (https://myorg-myenv.apigee.net/edgemicro-auth/publicKey) and the list of products (https://myorg-myenv.apigee.net/edgemicro-auth/products).

Need a clean way to disable polling for new configuration.

This is the place where it's handled.

Using Apigee Edge Microgateway Version 2.1.2, Trying to configure Apigee Edge settings. Below error is seen. Had anyone seen similar issue ? Any idea what's happening behind the scenes ? Any information regarding same will be helpful.

$> edgemicro configure -o xxxx -e test -u [email protected]

{ [Error: cannot GET https://XXXX-test.apigee.net/edgemicro-auth/publicKey (500)]

text: '{"fault":{"faultstring":"Script node is still starting","detail":{"errorcode":"scripts.node.runtime.ScriptStillStarting"}}}' }

PS: Running same command once again solved the issue, Interested to know what exactly hapenning behind scenes.

We need to better handle this error [maybe a retry]

I’m running into an issue with random “invalid token” when testing my local instance of the microgateway.

Running the following command over and over on my instance of microgateway returns a “401 Invalid Token” error randomly:

curl -i http://<myipaddress>:8000/v1/demo/docusign/ -H "x-api-key: jy4nTLfezVoG4d5Da7OCOYgUYL24aoag"

The errors happen randomly, but quite often. When we try running the same command using a different microgateway server (Dave Ryan’s machine) it works every time, but for some reason when run on my machine I see these errors. It happens when running curl from the terminal window or when running it from Postman. I’m running microgateway v2.57 on nodejs v8.6.0

Here is the output that is returned when it fails:

gateway:main selected proxy https://demo.docusign.net/restapi/v2 with base path /v1/demo/docusign for request path /v1/demo/docusign/ +50s
  gateway:main sourceRequest +0ms f7c82f00-a932-11e7-a65a-c54964e7f062 GET /v1/demo/docusign/
  plugin:oauth invalid token +50s
  plugin:oauth auth failure 401 invalid_token  { 'cache-control': 'no-cache',
  'postman-token': 'acee92f7-c2c7-49dd-ba42-0068ca2914e1',
  'x-api-key': 'jy4nTLfezVoG4d5Da7OCOYgUYL24aoag',
  'user-agent': 'PostmanRuntime/6.3.2',
  accept: '/',
  host: '10.103.91.95:8000',
  'accept-encoding': 'gzip, deflate',
  connection: 'keep-alive',
  client_received_start_timestamp: 1507142202864 } GET /v1/demo/docusign/ +0ms
  gateway:errors invalid_token +117ms
  analytics flushing 1 records. 0 records remaining. +35ms

Here is the output that it returns when it succeeds:

  gateway:main selected proxy https://demo.docusign.net/restapi/v2 with base path /v1/demo/docusign for request path /v1/demo/docusign/ +1m
  gateway:main sourceRequest +0ms 06228000-a933-11e7-81fa-6751874d9626 GET /v1/demo/docusign/
  plugin:oauth product only: false +1m
  plugin:oauth matches proxy rules: /v1/demo/docusign/ +0ms
  plugin:oauth matches proxy rules: /v1/demo/docusign/ +0ms
  plugin:oauth api key cache skip jy4nTLfezVoG4d5Da7OCOYgUYL24aoag +0ms
  gateway:main targetRequest +146ms 06228000-a933-11e7-81fa-6751874d9626 GET demo.docusign.net NaN /restapi/v2/
  gateway:main plugin oauth does not provide handler function for end_request +1ms
  gateway:main targetResponse +377ms 06228000-a933-11e7-81fa-6751874d9626 200
  gateway:main plugin oauth does not provide handler function for response +0ms
  gateway:main [ null, null ] +0ms
  gateway:main req data +0ms 474
  gateway:main plugin oauth does not provide handler function for data_response +0ms
  gateway:main plugin analytics does not provide handler function for data_response +1ms
  gateway:main plugin oauth does not provide handler function for end_response +0ms
  analytics flushing 1 records. 0 records remaining. +515ms

See description. Docs on how to accomplish this can be found here: https://docs.apigee.com/api-services/content/using-oauth2-security-apigee-edge-management-api

TL;DR

The EMG custom plugin API does not allow safe initialization of async (remote or not) resources.

Problem

Custom EMG plugins provide an init() entry point, which synchronously returns a predefined list of other entry points dealing with HTTP traffic. As soon as init() returns, the plugin is expected to be able to deal with inbound HTTP traffic. However, initialization of some resources might require some time. This is the case for example to get a remote public key (to check for JWT token validity), or to open a local database.

Actually, most of the Node.js API being asynchronous, the EMG init() synchronous call forces us to be able to deal with early race condition, while this could be easily avoided.

module.exports.init = function(config, logger, stats) {
  return {
    ondata_response: function(req, res, data, next) {
      debug('***** plugin ondata_response');
      next(null, null);
    },
    onend_response: function(req, res, data, next) {
      debug('***** plugin onend_response');
      next(null, "Hello, World!\n\n");
    }
  };
}

Our Recommendation

Add an optional 4th parameter "next" to the init() call, being a Node.js callback:

1. If absent (function arity === 3), then init() synchronously returns the expected list of HTTP handler. This is the current API & the current behavior: it maintains backward compatibility.
2. If present (function arity === 4), init() returns nothing and calls next() with error or data payload, depending on the initialization success, according to the Node.js callback model.

Example custom plugin source code using async init():

 module.exports.init = function(config, logger, stats, next) {
  db.open('./mydb.sql', function(err, mydb) {
    if (err) {
      next(err); 
    } else {
      next(null, {
        ondata_response: function(req, res, data, next) {
          debug('***** plugin ondata_response');
          next(null, null);
        },
        onend_response: function(req, res, data, next) {
          debug('***** plugin onend_response');
         next(null, "Hello, World!\n\n");
        }
      }
   });
};

As per documentation ( http://docs.apigee.com/microgateway/latest/edge-microgateway-operations ) it is possible to configure edge-microgateway to use proxy server for all outbound connections ( edge-microgateway -> backend server ):

"proxy: (default: none) Specifies the URL of a proxy server. If specified, all requests from Edge Microgateway will be sent via a connection to this proxy server. For more information, see Proxies in the Node.js request package documentation."

Unfortunately this works only partially - looks like only requests to *.apigee.net are being sent through configured proxy server.
Tested version : edge-microgateway version - 2.1.2.

I`ve also tried setting http_proxy / https_proxy on OS level ( export http_proxy="<proxy_ip>" and export https_proxy="<proxy_ip> ) and adding http-proxy , https-proxy and proxy to npm config file. Unfortunately this doesn't help.

Configured a simple passthrough proxy on demo24 and demo34 orgs with edgemicro init and configure steps. I see below issues with versions 2.4.6 and the latest 2.5.4

1. When a quota policy is introduced in configure YML, edgemicro start fails with error:

/usr/local/lib/node_modules/edgemicro/node_modules/volos-quota-common/lib/quota.js:158
  throw new Error(util.format('%s must be a number', name));
  ^

Error: interval must be a number
    at checkNumber (/usr/local/lib/node_modules/edgemicro/node_modules/volos-quota-common/lib/quota.js:158:9)
    at new Quota (/usr/local/lib/node_modules/edgemicro/node_modules/volos-quota-common/lib/quota.js:52:22)
    at Object.create (/usr/local/lib/node_modules/edgemicro/node_modules/volos-quota-apigee/lib/apigeequota.js:56:10)
    at /usr/local/lib/node_modules/edgemicro/node_modules/microgateway-plugins/quota/index.js:25:23
    at Array.forEach (native)
    at Object.module.exports.init (/usr/local/lib/node_modules/edgemicro/node_modules/microgateway-plugins/quota/index.js:17:23)
    at wrapper (/usr/local/lib/node_modules/edgemicro/node_modules/lodash/index.js:3095:19)
    at Plugins.loadPlugin (/usr/local/lib/node_modules/edgemicro/node_modules/microgateway-core/lib/plugins.js:58:18)
    at Gateway.addPlugin (/usr/local/lib/node_modules/edgemicro/node_modules/microgateway-core/index.js:57:37)
    at /usr/local/lib/node_modules/edgemicro/lib/plugins.js:58:13

2. On filling up all the products in org with quota numbers, I get past the above error but land up in below issue and quota is not enforced.

edgemicro start -o demo34 -e test -k <key> -s <secret>
current nodejs version is v6.11.0
current edgemicro version is 2.4.6
info: jwt_public_key download from https://demo34-test.apigee.net/edgemicro-auth/publicKey returned 200 OK
info: products download from https://demo34-test.apigee.net/edgemicro-auth/products returned 200 OK
info: config download from https://edgemicroservices-us-east-1.apigee.net/edgemicro/bootstrap/organization/demo34/environment/test returned 200 OK
PROCESS PID : 40705
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota
Not enough info for configuring quota

Config YML:

edge_config:
  bootstrap: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/bootstrap/organization/demo34/environment/test
  jwt_public_key: 'https://demo34-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://demo34-test.apigee.net/edgemicro-auth/products'
edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  max_times: 300
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
      - quota
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  verify_api_key_url: 'https://demo34-test.apigee.net/edgemicro-auth/verifyApiKey'
analytics:
  uri: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/axpublisher/organization/demo34/environment/test

demo34-test-cache-config.yaml.txt

Ingress would have to check that host headers are valid for given namespace. When namespace is created (Deployment API), there should be an API to do CRUD of valid host headers.

Problem Statement

Each EMG plugins needs to be installed (or linked to) <EDGEMICRO_HOME>/plugins. A plugin is made (at a minimum) of a package.json and an index.js, which makes it looking like a legitimate NPM module.

In order to integrate an EMG custom plugin as a real legitimate NPM module (from the public NPMjs.com or from a private NPM registry), one need to install it & then symlink it into the EMG plugins folder…

$ npm install -g my-npm-module
$ cd <EDGEMICRO_HOME>/plugins
$ ln -s <NPM-PATH>/my-npm-module my-emg-plugin

...and finally edit the ~/.edgemicro/<org>-<env>-config.yaml to insert it into the plugins: list.

  plugins:
    sequence:
      - oauth
      - my-emg-plugin

These are multiple operations, both at NPM, Shell & configuration level. They could be made simpler (and less OS-specific) using only NPM & EMG configuration.

Possible Solutions

1. Use the NPM module resolver (load them using require(‘my-emg-plugin’) as a fallback for plugins not found into <EDGEMICRO_HOME>/plugins.
2. Add a manual mapping between NPM modules and EMG plugin names in ~/.edgemicro/<org>-<env>-config.yaml, like (for example) the below.
3. Download custom plugin & its configuration from Edge Cloud (much like Edge Cloud Call-Out policies)

  plugins:
    npm:
      - my-emg-plugin
        my-npm-module
      - my-other-emg-plugin
        my-other-npm-module
    sequence:
      - oauth
      - my-emg-plugin

Recommendation

Proposal (2) above adds more information in the configuration file, but gives complete control to the developer of the NPM module names (eg. can adopt a naming convention to differentiate them from other general purpose NPM modules like ‘edgemicro-plugin-my-logic’) and the EMG plugin name (eg. ‘my-logic’)

Running edgemicro verify fails on verifying products availability. Not sure why this is failing because if I do a GET on {auth-uri}/products it returns a 200 OK with a list of products and info.

I did look at the code a bit, verify.js specifically and I don't quite understand the productsUrl constant that is constructed for the verify request.

// verify products endpoint availability
const productsUrl = util.format(authUri + '/products', options.org, options.env);

It produces the following uri which is not valid so this would always fail unless I'm missing something.
productsUrl = {auth-uri}/products myorg myenv

edgemicro verify -k redacted-key -s redacted-secret -o myorg -e myenv
current nodejs version is v8.3.0
current edgemicro version is 2.5.4
info: jwk_public_keys download from null returned 200 undefined
info: jwt_public_key download from {auth-uri}/publicKey returned 200 OK
info: products download from {auth-uri}/products returned 200 OK
info: config download from {edgemicro-uri}/bootstrap/organization/myorg/environment/myenv returned 200 OK
verifying analytics negative case: OK
verifying bootstrap url availability:OK
verifying jwt_public_key availability: OK
verifying products availability: FAIL
verification complete

Problem

It is common to use DNS CNAME (alias) to refer to a unique machine using different host-names, in order to clarify which service this machine is expected to run. Likewise, it is practical to refer to the same (composite) service from several CNAME's, to give an indication of which role the service is expected to play. However, it is not today possible to use the target hostname (CNAME) as part of an API proxy definition, so it is not possible from a unique EMG instance to differentiate the traffic headed to different roles of the same service.

For example, a "messaging" service having both the "email" and "sms" capability might be reachable from "messaging.example.com", "email.example.com" and "sms.example.com". It would be very convenient to be able to define multiple API proxies, (with command and different target endpoints) depending on the target hostname (or a pattern/regex on this hostname)

Suggestion

Add a hostname glob-matching (resp. regexp-matching) hostname in the API proxy definition. Default value would of course be "" (resp. ".").

Hi

Variable disable_config_poll_interval (used there ) is documented as disabled_config_poll_interval (with an extra 'd' after disable) there.

Can you fix this discrepancy ?

All the best

While attempting to perform a reload of the edgemicro gateway we were unable to specify the configuration file directory and always defaulted to the home directory in which the file did not exist. I'm thinking the reload command should also support the configuration location flag of -c as well since this doesn't work when using a configuration file stored outside of the users home directory.

We are currently running this version:
node_modules/edgemicro/cli/edgemicro --version
current nodejs version is v8.3.0
current edgemicro version is 2.5.4
2.5.4

$ npm install edgemicro@alpha
npm WARN deprecated [email protected]: This package is no longer supported. It's now a built-in Node module. If you've depended on crypto, you should switch to the one that's built-in.
[...]

As un-maintained, is the crypto module coming with edgemicro safe?

I have v2.5.4 installed, but tried running "edgemicro upgradeauth" to see if what it does. I got the following error where it seems to be looking in the wrong place for the edgemicro-auth proxy in my installation. Proxy is actually here: /Users/willwitman/npm/lib/node_modules/edgemicro/node_modules/microgateway-edgeauth

edgemicro upgradeauth -o docs -e test -u [email protected]
current nodejs version is v6.9.1
current edgemicro version is 2.5.4
password:
Error: Proxy base directory /Users/willwitman/npm/lib/node_modules/edgemicro/cli/lib/node_modules/microgateway-edgeauth does not exist
at getDeploymentInfo (/Users/willwitman/npm/lib/node_modules/edgemicro/node_modules/apigeetool/lib/commands/deployproxy.js:162:10)
at /Users/willwitman/npm/lib/node_modules/edgemicro/node_modules/apigeetool/lib/commands/deployproxy.js:88:7
at /Users/willwitman/npm/lib/node_modules/edgemicro/node_modules/async/lib/async.js:718:13
at Immediate.iterate (/Users/willwitman/npm/lib/node_modules/edgemicro/node_modules/async/lib/async.js:262:13)
at runCallback (timers.js:637:20)
at tryOnImmediate (timers.js:610:5)
at processImmediate [as _immediateCallback] (timers.js:582:5)

If any edgemicro proxy has a hyphen in its name, eg: edgemicro_test-proxy, then microgateway doesn't recognize it and responds with 404 Not Found error to the requests.