I am a beginner in middleware technology. I have started with WSO2. Now I learned that WSO2 has a caching feature at different places. Two of them is at Key Manager caches Keys and Response Caching.
My question is very simple (naive), that if we are caching wrong Response, we will get the response again.
For example:
I hit this dummy API request http://dummy.restapiexample.com/api/v1/employees which supposed to give a list of employees, but it gives me null or something else. Now, this response is cached in response cache, which means I will keep on getting null. Which is wrong. Caching makes sense, but it is caching all responses, wrong and right. So how it handled, what's the concept?
Similarily for Key Manager. What is the point of caching keys at both the API Gateway level and Key Manager level? We anyways have to re-generate it if it is a wrong key or expired key.
Please answer. My questions sound naive but appreciate if you can explain.
Yes, agree with you. Ideally, the cacheable responses should be picked based on the status code. I just created a feature improvement request.
However, this is already supported by the runtime, only the UI is missing it.
So you can make this working by changing a configuration file.
For that, open repository/resources/api_templates/velocity_template.xml and search for <cache scope="per-host" collector="false". (Note collector=false)
Then, add the <protocol> tag just above the <implementation> tag like this.
<cache scope="per-host" collector="false" hashGenerator="org.wso2.carbon.mediator.cache.digest.REQUESTHASHGenerator" timeout="$!responseCacheTimeOut">
<protocol type="HTTP">
<methods>*</methods>
<headersToExcludeInHash/>
<responseCodes>2[0-9][0-0]</responseCodes>
<enableCacheControl>false</enableCacheControl>
<includeAgeHeader>false</includeAgeHeader>
<hashGenerator>org.wso2.carbon.mediator.cache.digest.REQUESTHASHGenerator</hashGenerator>
</protocol>
<implementation type="memory" maxSize="500"/>
</cache>
Note the regex for 2xx responses in responseCodes. I hope this answers your 1st question.
Regarding the key caches, yes, there are caches at both gateway and keymanager. But by default, only the gateway cache is enabled.
<CacheConfigurations>
<!-- Enable/Disable token caching at the Gateway-->
<EnableGatewayTokenCache>true</EnableGatewayTokenCache>
<!-- Enable/Disable API resource caching at the Gateway-->
<EnableGatewayResourceCache>true</EnableGatewayResourceCache>
<!-- Enable/Disable API key validation information caching at key-management server -->
<EnableKeyManagerTokenCache>false</EnableKeyManagerTokenCache>
And there are cases where some want to disable gateway cache and enable keymanager cache, for example when the gateway is in DMZ.
Related
I read documents online. They say that
A GET-Ajax request is used for getting data from the server.
A POST-Ajax request is used for change data on the server.
But why is it?
A Get-Ajax request can change the data on the server TOO, right?
Why should only the POST-Ajax request change the data?
Is it because of a security reason or something? Please explain to me
GET and POST are different methods for web requests that provide different features/describe different intentions for programmers and APIs. You are correct that, technically speaking, if you want to do some other CRUD operation on the server when using a GET request, you can. Most would probably argue that this is not a good idea, in part for security/performance features that either method provides. Example: GET requests can be cached, POST cannot.
More on that here: https://www.w3schools.com/tags/ref_httpmethods.asp
I am using Retrofit/OkHTTP to consume a REST API which doesn't provide proper cache headers. In order to work around this, I've written a cache interceptor which will add cache control headers to the response.
I have seen in multiple places this is considered dangerous, for example the okhttp recipe for this has the following comment:
/** Dangerous interceptor that rewrites the server's cache-control header. */
(source)
Why exactly is this considered to be dangerous? I'd like to understand the risks of doing this.
You're making decisions on the client that should instead be made on the server. The risk is that the client ends up caching something it shouldn't, which will result in stale data being returned.
Hi I am trying to get records from incident table from a serviceNow instance using the ServiceNow connector from ESB. I am able to get back the filtered query records from incident table using the respond mediator.Can anybody tell me the way to cache these records in a detailed way?Thanks
You can use cache mediator to cache the response message. you can refer more at here.
You can achieve this using the cache mediator. You don't necessarily need to have the configuration in in-sequence and out-sequence respectively. Please try the following.
<cache timeout="20" scope="per-host" collector="false" hashGenerator="org.wso2.carbon.mediator.cache.digest.DOMHASHGenerator">
<implementation type="memory" maxSize="100"/>
</cache>
This is where the request's hash is generated to store in the cache. If you have this segment at the request which you need to cache, that would suffice.
<cache scope="per-host" collector="true"/>
This where the response is being cached. You can add this right after the ServiceNow call. If the request matches the hash when it reaches the first configuration it will respond to the client from the cache this way.
This is the first time I`m toying with PhoneGap, so I actually never needed Cross Origin Resource Sharing (CORS) before.
It is by default blocked, and the options I found in the web are either hacks or insecure.
My question is: What is the best or proper way to accomplish server integration using PhoneGap?
Bear in mind:
I need session control serverside to keep the user logged in
The request is coming from a file in PhoneGap's webview so origin = null
I'm using PHP serverside and have full control over it
<access origin="*" /> is already added to config.xml (it enables me to reach out for the server, but doesn't guarantee it will respond to a cross-origin request)
A long search on the web lead me to:
Access-Control-Allow-Origin *
Access-Control-Allow-Credentials true
But I understood they're rather unsafe, specially combined.
I could save the user session ID locally, but that seems hacky and unsafe.
There's also JSONP to the rescue, but that also seems hacky, unsafe and won't persist my session ID.
I could use a proxy server, but that seems far from optimal and as I understand it'll be hard to prevent an attacker to not use this same proxy server to perform the same operations.
Hi you can disable security to browser and use it.
Please find the link for disabling security for chrome.
[Disable same origin policy in Chrome
Cookies support - Problem?
Original Issue/Background:
We have API based on servlet / JSON running in Openshift, the web server used in openshift is Tomcat.
We store information to httpsession and everything works fine when used directly against openshift / tomcat (POST / GET). But when we configured apigee against existing methods the session is lost. Stuff is stored correctly in the session in server side, but when second request comes from apigee into the tomcat the session is "lost"
Piece of java code to get the session is plain httpsession.getRequest(). As said this works fine when using backend directly. Is there some additional steps (cookies etc) needed to maintain the session when requests are used through apigee?
Update Findings;
With short debug an traffic monitoring the reason of the error in apigee is confirmed to be that it does not pass JSessionId to requests. This means that cookies support should be enabled somehow in the API proxy settings / Configuration.
Anyone have an idea where or if this can be resolved?
First off, cookies aren't part of a proper RESTful payload -- if you grabbed the headers you could store them with an access_token as part of the generate token policies.
That aside, you should be able to pass the cookies back to the requesting App and then let the app pass them back to the API -- my jokeindex API lets you do this.
Make sure you don't have any AssignMessage policies in the flow that are stripping out the headers accidentally -- something like this:
<Set>
<Headers />
</Set>
as that will remove ALL headers. Also, you can look at the Trace tool in Apigee to check each policy step along the way to see if you're stripping the Cookie: header from the requesting payload.
When you have your resource on address "http://yourdomain.com/somewhere/", and you redirect to that resource from apigee API, for instance by url: http://yourapi.apigee.net/v0/myresource" what you get back from your server is cookie for /somewhere/ not v0/resource/somewhere, so basically when browser gets cookie back, it does not put it into correct place and discards it. At least that was/is my case.
You should ping #bissell about this but I did find this article that might be helpful:
http://community.apigee.com/groups/learn-create-and-manage-apis/some-basic-questions-new
Also, you might be able to fix your issue by adding an "extract variable" policy to the request that captures the JSessionId and then adding an "assign message" policy to add it back to the request.
You can assign policies from API Platform>Dashboard>API Proxies>YOUR API>Develop