16.09.21 - Apigee Edge for Public Cloud release notes

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info

On Thursday, October 13, 2016, we began releasing a new version of Apigee Edge for Public Cloud.

New features and updates

Following are the new features and updates in this release.

Shared Flows and Flow Hooks to operationalize API proxies (beta-by-request only)

A new "Shared Flows" feature lets you operationalize functionality in API proxies. By combining conditionalized policies and resources into a Shared Flow, you can reference it from any API proxy to execute single-source, reusable logic. For example, a Shared Flow might verify the API key, protect against spike arrests, and log data.

You define Shared Flows in the management UI (APIs > Shared Flows), then reference them in two different ways:

With a new Flow Callout policy in an API proxy
or
On a new artifact called Flow Hooks, which are in the following locations:
- Request: Before the ProxyEndpoint PreFlow, after the TargetEndpoint PostFlow
- Response: Before the TargetEndpoint PreFlow, after the ProxyEndpoint PostFlow
These attachment points let you execute operational logic before or after the main flow points of the individual proxy. You assign Shared Flows to these Flow Hook locations in the management UI (APIs > Environment Configuration > Flow Hooks).

Encrypted key value maps

You can create encrypted key value maps (KVMs) for storing sensitive information such as credentials or PII/HIPAA data. This feature is different than the existing Edge secure store (vault) and is designed to supplant it, as vault values can be accessed only with Node.js (in addition to the management API). You can access encrypted KVM values with Node.js or the Key Value Map Operations policy.

Creating encrypted KVMs

Use the existing KVM APIs. When you include “encrypted”: “true” in the payload definition when creating a KVM, Edge encrypts the KVM and generates an encryption key that has the same scope as the KVM.
You cannot use the Key Value Map Operations policy to create an encrypted KVM.
You cannot encrypt an existing unencrypted KVM.

Using encrypted KVMs

Use the Key Value Map Operations policy to get and update encrypted KVM values.
When getting an encrypted key value, prefix the variable to hold the value with "private." For example: <Get assignTo="private.secretVar">. That private.secretVar variable holds the decrypted value.
When updating a value with the policy, you don't need to do anything special. The value will be encrypted automatically in encrypted KVMs.
You can also access the decrypted value using the apigee-access module in Node.js code. Use the function getKeyValueMap() to retrieve a KVM based on the name and scope. Two functions are available on the returned object: getKeys(callback) to get an array of key names and get(key, callback) to get the value for a particular key. For example:
```
var apigee = require('apigee-access');
  var encryptedKVM = apigee.getKeyValueMap('VerySecureKVM', 'apiproxy'); 
  encryptedKVM.get('secret1', function(err, secretValue) { 
  // use the secret value here 
});
```

(APIRT-1197)

Warning:

KVM PUT operations with null keys

If a Key Value Map Operations policy tries to PUT a new key/value in a key value map (KVM) using a null key, the following key is auto-created: __$$_EDGE_KVM_EMPTY_KEY_$$__

This situation would happen, for example, if you're populating a key using a variable reference and the referenced variable is null. As new PUTs with null keys are attempted, only that key is used, so existing values for that key are potentially overwritten each time the policy is executed.

The previous behavior for a null key was that the key/value was not added to the KVM. Instead, the entry remained in the message processor's in-memory cache and was temporarily available for subsequent Get operations. If your KVM policy implementation relies on the previous behavior, Get operations on null keys will now fail because they're not referencing the new key name (above) that gets created for null keys. (APIRT-3530)

OpenAPI Spec URLs included in API proxy metadata

When you create an API proxy based on an OpenAPI Specification, the location of the OpenAPI Spec is stored in the API proxy metadata. For example, if you use the management API to get the details of a proxy revision, the metadata includes the path to the OpenAPI Spec in the following format:

"spec" : "https://raw.githubusercontent.com/apigee/api-platform-samples/master/default-proxies/helloworld/openapi/mocktarget.yaml"

This enhancement supports the next-generation version of Edge, which links OpenAPI Specs to API proxies, API products, and API reference docs in the new developer portal. (MGMT-2913)

Client IP control with Sense

In order to more accurately control where to find IP addresses for Sense bot detection when using routing products such as Akamai, Sense lets you define the location of the client IP with an additionalIPVars variable. For example, you can set additionalIPVars to use the true-client-ip header, which contains the correct IP from Akamai to evaluate in bot rules. (APIRT-3332)

Bugs fixed

The following bugs are fixed in this release. This list is primarily for users checking to see if their support tickets have been fixed. It's not designed to provide detailed information for all users.

Issue ID	Description
APIRT-3507	Intermittent errors (such as SNI errors) on JavaScript service callouts
APIRT-3408	MP release 160817 apigee-access analytics module processing messages differently
APIRT-3390	Change in fault response returned by refresh access token policy Warning: Change in OAuthV2 error code "invalid_client". Note the following change to an error code thrown by the OAuthV2 policy operations GenerateAccessToken and RefreshAccessToken when the OAuthV2 policy's <GenerateResponse> property is set to false: `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` has been changed to: `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` It is recommended that you change any fault rule conditions that trap "`invalid_client`" to catch both the old and new codes. For example, in your fault rule, change: `(fault.name = "invalid_client")` to this: `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT-3389	Warning: Error uploading Node.js payloads over 25KB Uploading Node.js payloads over 25KB is now allowed.
APIRT-3381	High latencies on customer production proxies
APIRT-3366	Javascript policies are failing on all new Trial organizations
APIRT-3363	Invalid URL parsing returns a 500 status with ApplicationNotFound
APIRT-3356	OAuth invalid token message
APIRT-3355	Intermittent 403 error on OAuth proxy
APIRT-3285	Warning: Inconsistent OAuth2 token expiration When generating an OAuth token using the OAuth v2.0 policy, you can set the token expiration either by reference or a hard-coded default. For example: `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. The first time the token expiration was set by reference, Edge stored and used that value for every new token expiration. This bug has been fixed to use either the reference value or, if no reference value is provided, the default expiration defined in the policy. This fix may change the duration of your token expirations, and you may experience side effects such as more invalid token errors, which may require you to implement more frequent token refreshes or change the default expiration in your OAuth policies.
APIRT-3261	Credentials are validated against another dev app in production
APIRT-3234	Node.js app returns NPE
APIRT-3223	Apigee stale cache issue
APIRT-3193	Node.js target server is hanging after move to ASG
APIRT-3152	cachedlogs management call causes log messages to be broken up
APIRT-3117	MP reached 100% CPU utilization and stopped serving traffic
APIRT-3064	Router - custom 503 error message from router
APIRT-2620	Separate thread pool for some blocking steps to improve load handling
CORESERV-774	Access using valid key with invalid apiproduct reference causes internal server error