I'm using the Postman packaged app + the interceptor extension. It seems that chrome adds an Origin: chrome-extension://aicmkgpgakddgnaphhhpliifpcfhicfo header automatically for requests that come from Postman. I want to remove this header completely.
When using the Interceptor extension, if I use the regular Postman headers tab to enter an entry for the Origin header, then my request uses the specified value. So, I can change the value of the header. I then tried leaving the value field blank for the header, but then my request reverts to sending Origin: chrome-extension://....
How do I send a request with postman that either sends a blank Origin header, or totally omits it?
I tried it by myself and hope my solution will suit you.
When I make a POST request using Chrome app it adds origin header.
But when I use the desktop app no header is added to my POST request.
Here is an example of header sent by the desktop Postman app:
I am unable to use Postman desktop app (corporate policy yey!) so I'm stuck with Chrome extension Postman.
I was able to overwrite the Origin header by installing Postman Interceptor extension. You also need to active the Interceptor app in Chrome AND Postman.
More detailed instructions can be found here: https://stackoverflow.com/a/41564921/1169726
Related
i am playing around with Postman to get some insight on how things work behind the curtain and ran into, what I believe, is an issue but wanted to ask before I create a new issue on GitHub.
I am intercepting the request from my browser to the same site using the Postman Interceptor to use the request values in the native app. I have cookies enabled and the site (the whole domain) whitelisted.
When I use the history to resend the same request that was captured I get an auth error that is caused by the fact that the cookies are not included in the request (found that out by checking the cURL code snippet). I believe the reason for that is, that the cookies are set under another sub domain than that the request is send to.
I will try to include some pictures to clarify. My question here is:
Am I missing something/did I set something up in the wrong way
or is this an issue and I should create an issue in the official Postman Github page
cURL request
Cookies in Postman Native App
you should see if cookie is being send not using code snippet but the console :
its indeed sending cookies ,
i'm using wso2 api manager(version 2.1.0) to expose some rest api. i need to send "Cookie" as header to some of my rest api(s). I use "API Manager store" to test rest api (https://localhost:9443/store) . but when i set Cookie as Header Request i see this log in browser and call failed :
Refused to set unsafe header "Cookie"
but when i use any other headers like "customHeader" it works fine.
in API_HOME/repository/conf/api-manager.xml , i change this line :
<Access-Control-Allow-Headers>Cookie,customHeader,authorization,Access-Control-Allow-Origin,Content-Type,SOAPA</Access-Control-Allow-Headers>
I also enable "Enable API based CORS Configuration" in api manager publisher (https://localhost:9443/publisher)
I really stuck in this.
is there any way to set Cookie header in api manager?
Thanks in advance
Actually you can't set Cookie header that way.
Browsers restrict the way you create cookies allowing you to set a cookie only for a specific domain and path and with a specific expiration time.
Cookie header is a set of all headers defined to the request domain and path, so you cannot directly overwrite this header.
Setting an HTTP Cookie involves sending Set-Cookie header with the values you want to set.
Check this out:
5.4. The Cookie Header
4.1. Set-Cookie
HTTP cookies explained
I've run into a few problems with setting cookies, and based on the reading I've done, this should work, so I'm probably missing something important.
This situation:
Previously I received responses from my API and used JavaScript to save them as cookies, but then I found that using the set-cookie response header is more secure in a lot of situations.
I have 2 cookies: "nuser" (contains a username) and key (contains a session key). nuser shouldn't be httpOnly so that JavaScript can access it. Key should be httpOnly to prevent rogue scripts from stealing a user's session. Also, any request from the client to my API should contain the cookies.
The log-in request
Here's my current implementation: I make a request to my login api at localhost:8080/login/login (keep in mind that the web-client is hosted on localhost:80, but based on what I've read, port numbers shouldn't matter for cookies)
First the web-browser will make an OPTIONS request to confirm that all the headers are allowed. I've made sure that the server response includes access-control-allow-credentials to alert the browser that it's okay to store cookies.
Once it's received the OPTIONS request, the browser makes the actual POST request to the login API. It sends back the set-cookie header and everything looks good at this point.
The Problems
This set-up yields 2 problems. Firstly, though the nuser cookie is not httpOnly, I don't seem to be able to access it via JavaScript. I'm able to see nuser in my browser's cookie option menu, but document.cookie yeilds "".
Secondly, the browser seems to only place the Cookie request header in requests to the exact same API (the login API):
But, if I do a request to a different API that's still on my localhost server, the cookie header isn't present:
Oh, and this returns a 406 just because my server is currently configured to do that if the user isn't validated. I know that this should probably be 403, but the thing to focus on in this image is the fact that the "cookie" header isn't included among the request headers.
So, I've explained my implementation based on my current understanding of cookies, but I'm obviously missing something. Posting exactly what the request and response headers should look like for each task would be greatly appreciated. Thanks.
Okay, still not exactly what was causing the problem with this specific case, but I updated my localhost:80 server to accept api requests, then do a subsequent request to localhost:8080 to get the proper information. Because the set-cookie header is being set by localhost:80 (the client's origin), everything worked fine. From my reading before, I thought that ports didn't matter, but apparently they do.
My app is an Ember.js front end with a Go API on the server. I created the Ember app using the FixtureAdapter. Now that I have the Go API back end I converted it to RESTAdapter.
When I hit my API directly with the browser, I seem to get the appropriate CORS headers back:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:Origin,x-requested-with
Access-Control-Allow-Methods:PUT,PATCH,GET,POST
Access-Control-Allow-Origin:*
Access-Control-Expose-Headers:Content-Length
However, when my Ember.js app hits the API, I get XMLHttpRequest cannot load https://192.168.59.103:8001/notifications. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://192.168.59.103:9000' is therefore not allowed access..
I don't know how else to see what's going on between Ember and the API. I've read this CORS tutorial and everything seems to be okay on the server end.
I included the bit about x-requested-with because of another Stack Overflow question suggesting that jQuery requests need something different than plain old JavaScript requests.
Your endpoints also need to respond with CORS headers to OPTIONS requests- those will execute before the actual request to make sure that the request is allowed first.
Do you happen to be using Nginx as your reverse proxy for your API? If so, we experienced this same issue. In our case, the problem was that Nginx returns the correct CORS headers just fine for HTTP 200 OK responses, but for any error response, it will fail to add the COR headers and therefore the actual server response gets obscured by the browser complaining that it doesn't have the appropriate CORS headers to render a response.
See https://serverfault.com/a/431580/199943.
Even if you're not using Nginx, try calling your API directly (e.g. using Postman to avoid the CORS restrictions to see what it's returning. If your API is returning anything other than an HTTP 200 OK, that may be why the CORS headers aren't getting added.
I have a VB.NET app that sends a POST request to a script on my server that is running Cloudflare. I always get an error when sending the request from the app, however using a Firefox extension to simulate the request works fine. With the use of Fiddler I think I have found the cause of the problem:
When sending the request with the Firefox addon an extra header is attached to the request:
Cookie: __cfduidxxxxxxxxxxxx
This cookie is from Cloudflare, but where does it come from, ie. how can I get this cookie value and send it with my requests from the VB app? I tried copying and pasting the cookie into the app and it worked fine, so this leads me to conclude that I need this cookie, however this value is unique for each user so I cannot simply hardcode it into the app.
Quick side-note: Not sure if this helps, but if I send a GET request from the VB app it works fine without the __cfduid cookie.
Look for a Set-Cookie header coming back from the server on it's response. It will expect to get that value back on subsequent requests in a Cookie: header. This value is usually an opaque string that is classified by a path, although not always.