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
Related
I would like to start by saying that I have gone through several answers on related topics here and none seems to fix my issue.
I have created a new thread group and added a new header manager and cookie manager to it. I have 3 https requests in the thread group. The first call is an authentication call which needs no cookies. This call returns 3 cookies in response headers that I need to pass for further requests.
Authentication call is working fine. But the calls after authentication is not working since the cookies are not set. I have added 'CookieManager.check.cookies=false' to the user.properties file and still seeing '[no cookies]' in all requests. I have also tried adding a dummy cookie to the cookie manager under 'User-Defined Cookies' section as shown in the screenshot and even that cookie is not added to the requests.I am getting '[no cookies]' in all requests.
I have also tried all options under policy manager like standard, compatible etc without any success. Also tried this in Jmeter 3.1 and 3.3 (latest version) and the same issue observed.
Any suggestions or solutions are highly appreciated.
To add a custom cookie you must set its Domain to your application domain, otherwise it will not be picked up
Your Path should start with a forward slash / and need to match the request URL path , however it is better to remove anything from that input
It might be the case you're suffering from Bug 56358 so consider upgrading to JMeter 3.3, it can resolve your issue
As a last resort you can always fetch cookies you need from the Set-Cookie response header using Regular Expression Extractor
You could also try going the dirty way and get the cookies values from the previous response and use them in the following parameters or store it. You can do this using a Post processor - Regular Expression Extractor that you put in the first Authentication request. Here is a site that explains how to use RegEx https://octoperf.com/blog/2017/09/07/jmeter-regular-expression-extractor/
I want to call REST-services from my Angular-app. However, these REST-services are hosted on WLP and are part of a WAR-file developed by some company a while ago, ie. we have no source code.
I can call GET-methods without any issues from Postman, I just need to set authentication and accept headers. However, calling these GET-methods from Angular via web browsers will trigger preflight request (OPTIONS) without Authentication header prop. Seems to me that OPTIONS requests are triggered by the browsers and Angular cannot set headers for them. I confirmed OPTIONS requests need authentication by running requests via Postman with and without auth header prop.
Similar problems were discussed in other posts on stackoverflow but in such cases people had control over their server side code and could alter it to avoid authentication headers for OPTIONS request. Clearly in my case, I cannot do it.
My question is if there is a possibility to configure WLP to not ask for authentication header prop in case of OPTIONS-requests (seems to be configurable for Apache web servers and Tomcat)?
Kind regards
A.H.
Even without source, you should be able to edit web.xml and modify the security-constraints to punch a hole for OPTIONS.
I know SiteMinder can add HTTP headers to the HTTP request so that backend devices (the web server, app server, etc) can have the headers for processing. But on the way out back to the client (browser), can SiteMinder add a HTTP Response Header so the client can use it?
I see a response type of WebAgent-HTTP-Header-Variable but it seems that is only accessible on the server side.
I've quick searched through some documentation and Googled, but the SiteMinder documentation is well, less than I would hope for. :)
From my recent understanding, HTTP Headers are only accessible at the server and never available on the client side unless the IIS/Web server/Application pushes them through.
Here is a link to CA's SiteMinder information that does NOT specify the above specifically:
https://wiki.ca.com/display/sm1252sp1/Default+HTTP+Headers+Used+by+the+Product
but it does say it passes it to the 'web application', which to me means only to the server.
So if you need the variable, you have to capture it at the server and send it to the client browser. In most cases this should NOT be done. Ask you company's security group for guidance here on SiteMinder headers. The company I work for created custom headers for my app, not the ones automatically sent from a canned SiteMinder installation.
I'm developing an iOS app that makes frequent requests to a web server, and I'm using AFNetworking (which I very much like). However, I'm running into a problem with authorization that I just can't solve.
The server requires me to provide an authorization header in order to get the response that I want. Specifically, the authorization headers should be like so:
Authorization = "ApiKey some-user-name:someNumericalApiKey"
I'm using AFNetworking throughout the project, and everything works fine, except for this authorization issue. I'm using the following code:
[myClient setDefaultHeader:#"Authorization" value:#"ApiKey some-user-name:someNumericalApiKey"];
where myClient points to an AFHTTPClient object. Strange enough, when I log the request in XCode using AFHTTPRequestOperationLogger, the logger claims that I have the correct headers set. However, the authorization header does not seem to reach the server - I can't see it in the server log.
To isolate the problem, I've tried to make the exact same request using good old NSURLRequest, as well as curl, and the requests library in Python - all of these work fine, i.e. the authorization header is sent & received (i.e. I can see it in the server log), and the server response is what it should be.
If anyone has run into the same problem (and has found a solution) I would very much appreciate to hear from you.
Thanks.
Sometimes (especially with Django) this is caused by redirection stripping of header parameters. For instance, /Object redirects to /Object/ in the background and removes the necessary auth parameter during the switch.
If you're using AFNetworkActivityLogger with level AFLoggerLevelDebug then you should be able to check this out in the console. If you see a POST request with /Object and the response with /Object/ then this might indicate redirection stripping is taking place.
If you construct your operation manually then the defaultHeaders are not applied, that might be the cause of your problem.
I have been trying to get this resolved, without any success.
I have a webapp residing on my domain, say www.myDomain.com. I need to call a service which is present on another domain, say www.anotherDomain.com/service.do?
I'm using SproutCore's SC.Request.getUrl(www.anotherDomain.com/service.do?) to call that service.
I get an error that says, Origin www.myDomain.com is not allowed by access-control-allow-origin.
When I was in dev stages, and using sc-server, the issue was resolved using proxies. Now that I have deployed the app to an actual server, I replaced all the lines where I had set up the proxy with the actual domain name. I have started getting that error again.
The problem is that I CANNOT MAKE ANY CHANGES to the server on the other domain. All the posts that I have come across state that the other server on the other domain ought to provide access-control-allow-origin header and that it ought to support the OPTIONS verb.
My question is, is it possible for me to connect to that service using SproutCore's SC.Request.getUrl() method?
Additionally, the other posts that I have read mentioned that a simple GET request ought not to be preflighted. Why then are my requests going as OPTION instead of GET?
Thanks a ton in advance! :D
This is not a Sproutcore issue; it's a javascript Same Origin Policy issue.
If you can't modify the production server, you have no option but to develop your own proxy server, and have your proxy hit the real service.
This is effectively replacing sc-server in your production environment.
All this server would do is take the incoming request and pass it along to www.anotherDomain.com/?service.do.
You would need to make sure you passed all parameters, cookies, headers, the http verb, etc....
This is far from ideal, because now errors can occur in more places. Did the real service fail? Did the proxy fail? etc.
If you could modify the other domain, you could
1) deploy your SC app there.
2) put in the CORS headers so you could make cross domain requests