api-policies's People
Forkers
littlecodeshop decimator02 nerdprogrammer sanjaykumarswarnkar kgaurav-mule ms3inc jr-mulesoft trknz jiaoxiongwei srimals jeyaramd locactus manimaditapunextdc bsound83 sergiopino leah1808 nisiem23 vinzon11 mammefen shatpath abhay93 ajay4581 kunamule harshakumarh vr56 apdwivedi1208 devskamat018 nawazqapi-policies's Issues
Web Service Security to Basic authentication transformation policy does not work in API Gateway 2.0
The transformation policy is not working in API Gateway 2.0. because is assuming that the runtime is including the class org.jboss.netty.buffer.ChannelBufferInputStream, but it is not. The policy can be fixed by replacing the previous invocation with java.io.InputStream.
Request Response Logging policy changes for compatibility with GW 2.0
I've seen the modifications you've done to this policy to work in 2.0. Most of the things are now working but there are still some changes to do:
- "http.headers" does not exist anymore with new HTTP transport, all the inbound properties referenced from this map should be referenced directly:
message.inboundProperties[http.headers]['Host'] -> message.inboundProperties['Host'] - MULE_REMOTE_CLIENT_ADDRESS should be replaced with http.remote.address
- "http.context.uri" should be replaced with "Host" and "http.request" with "http.request.uri""
All these new constants are in org.mule.module.http.api.HttpConstants class
Policies that use cxf:proxy-service does not work with the autogenerated wsdl proxies in API Gateway
As the policy is using a cxf:proxy-service, that component will provide you an invalid wsdl instead of giving you the one generated by the API Platform proxy's cxf:proxy-service (which modifies the wsdl of the user's web service) or the one generated by a cxf:jaxws-service. This is wrong, even if your webservice is secured, you must be able to retrieve the wsdl of it. The correct usage of this security component (if you have an API Platform proxy) would be to include it inside of the proxy's cxf:proxy-service (without using a policy).
Basic Auth to WS-Security Transformation Policy not working with GW 2.0
The policy does not work properly in GW 2.0 because with the new Http Module. Class org.jboss.netty.buffer.ChannelBufferInputStream is not compatible anymore since netty transport was removed in 2.0. The policy shouldn't be dependent of any specific transport internals (unless it is unavoidable).
To avoid the dependency it could be changed as follows.
The original policy has:
<!-- continue only if the message payloadof InputStream data type is present -->
<mule:message-filter xmlns:mule="http://www.mulesoft.org/schema/mule/core"
onUnaccepted="payloadViolation">
<mule:expression-filter xmlns:mule="http://www.mulesoft.org/schema/mule/core"
expression="#[payload instanceof org.jboss.netty.buffer.ChannelBufferInputStream]"
name="PayloadFilter"/>
</mule:message-filter>
And this should be fixed with:
<!-- continue only if the message payloadof InputStream data type is present -->
<mule:message-filter xmlns:mule="http://www.mulesoft.org/schema/mule/core"
onUnaccepted="payloadViolation">
<mule:expression-filter xmlns:mule="http://www.mulesoft.org/schema/mule/core"
expression="#[payload instanceof java.io.InputStream]" name="PayloadFilter"/>
</mule:message-filter>
The policy is failing when running on CloudHub/API Portal
CloudHub, AG 2.2.0
Tried applying the policy on an API.
The below response is produced
Execution of the expression "
app.registry['lock'].lock();
if (!app.registry['sn'].contains(key))
app.registry['sn'].store(key, payloadBck);
app.registry['lock'].unlock();
" failed. (org.mule.api.expression.ExpressionRuntimeException). Message payload is of type: String
:
response caching is not working
I tried it with my API.
I applied the response caching policy.
I hit the API many times but the subsequent request has greater response time compared to the first one.
Which is not the expected behavior.
/testAPI
-- | -- | -- | -- | --
|paramKey| Response Timeout
||1st Hit | 2nd Hit | 3rd Hit | 4th Hit
paramValue | 11236 ms | 8844 ms | 9099 ms | 9877 ms
HTTP headers add/strip policy is not working properly
This policy does not work properly in GW 2.0 and the previous versions. It attempts to remove headers (from the outbound properties map) as soon as they arrive to the app, but at that point:
- The outbound properties map is empty
- All the headers are located in the inbound properties map, which can not be modified.
Regarding to the proxies, as the inbound properties are copied to the outbound properties map just before making the request to the implementation api, the unwanted headers are sent anyway.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.