You're viewing Apigee Edge documentation.
Go to the
Apigee X documentation. info
On Thursday, January 30, 2014, we released a new cloud version of Apigee Edge.
New features and enhancements
- OAuth 2.0 update custom attributes on tokens
A new "Set OAuth v2.0 Info" policy lets you update custom attributes on OAuth 2.0 tokens.
http://apigee.com/docs/api-services/content/set-oauth-tokens-attributes-using-setoauthv2info
-
OAuth 1.0a policy updates
This release includes the following updates to the OAuth 1.0a policy:- As with OAuth 2.0 tokens, you can now set custom attributes on OAuth 1.0a tokens.
- A new GenerateVerifier operation lets you generate and return an OAuth 1.0a verifier (similar to an authorization code in OAuth 2.0).
- SSL info in flow variables
Apigee Edge now lets you propagate and access SSL information in flow variables. By setting a new "propagate.additional.ssl.headers" property on a ProxyEndpoint, you have access to the same SSL information available on an Apache web server.
http://apigee.com/docs/api-services/api/variables-reference
- JMS headers as HTTP headers
All JMS headers are now propagated as HTTP headers for downstream processing.
- Node.js module update
Apigee’s built-in Node.js module has been updated to include the following modules: argo 0.4.9, async 0.2.9, express 3.4.8, underscore 1.5.2, usergrid 0.10.7, volos-cache-memory 0.0.3, volos-oauth-apigee 0.0.2, volos-quota-apigee 0.0.2.
-
Custom roles in the management UI - BETA
In addition to the existing user roles of “Business User”, “Operations Administrator”, “Organization Administrator”, and “User”, this release includes a beta feature that lets you create custom roles in the management UI. You can control access to various Edge features using custom roles.
Bugs fixed
| Topic | Description |
|---|---|
| Custom role permissions | Permissions set using custom roles now work as expected. |
| API latency analytics | In an API proxy flow, when a call to the target system results in a timeout (such as an HTTP read timeout), the target latency times included in the API analytics. |
| “type” attribute on policies | The “type” attribute now functions correctly in all Apigee policies. |
| OAuth 2.0 invalidating tokens | The invalidating tokens functionality for Apigee OAuth 2.0 policies now matches the OAuth spec. You are no longer required to provide a “type” when setting the “token” parameter. |
| RBAC with key/value maps | Role-based access control now works for key/value maps created at the environment level. |
| OAuth 1.0a policy response format | When making requests to an API with an OAuth 1.0a policy, the response is now returned in the format of the Accept header. |
Known issues
| Topic | Description |
|---|---|
| HTTP 1.0 request, HTTP 1.1 response |
This issue involves a scenario where a client sends a request using HTTP 1.0 with the
content-length property in the header, but the backend service is
configured to use HTTP 1.1 and returns a transfer-encoding property for
chunked encoding instead.
To successfully handle this scenario, you can remove the
transfer-encoding
property from the HTTP 1.1 response using the AssignMessage policy. In the following
policy, which would be attached to the API proxy response flow, the
transfer-encoding property is removed from the HTTP header, which allows
the client to receive the response un-chunked.
<AssignMessage name="RemoveChunkedEncoding">
<AssignTo createNew="false" type="response"></AssignTo>
<Remove>
<Headers>
<Header name="Transfer-Encoding"/>
<Header name="transfer-encoding"/>
</Headers>
</Remove>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>
|