WSO2 API Manager Refused to set unsafe header "Cookie" - 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

Related

Access-Control-Allow-Credentials in combination with httpOnly - cookies

Through the header "Access-Control-Allow-Credentials" one can define that the response will be exposed and accessible to JavaScript.
From the Docs:
Credentials are cookies, authorization headers, or TLS client certificates.
When using Cors - Cookies I need to set this header to true (https://stackoverflow.com/a/46412839/6458608).
Through a "http-only" cookie I can define that a cookie should not be exposed in the JS - context.
This two configs are challenging each other, at least in my understanding.
Questions:
Is there some priority like "a http-only is never exposed to the JS - context even when the allow-credentials header is set"?
Do I need to consider something while using cors - cookies? Or can I tell for sure that I can never access a http-only - cookie in JavaScript?
These two settings are related, but don't challenge each other. In the case of http-only you are saying whether or not you'd ever have access to the value of the cookie in javascript.
On the other hand, the header Access-Control-Allow-Credentials is set by the server, to tell the browser whether javascript has the ability to tell the browser to send cookies on a CORS request (using the withCredentials flag on xhr). So, javascript would still not have access to the actual cookie values, it just now has a way to modify the browser behavior on when to send cookie values.
More information -
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials

Why isn't this cookie sent to other subdomains?

We have an authentication API for signing in and a file download API that serves protected files.
The authentication API lives at authentication.api.mysite.com and returns the following header on a successful sign-in:
Set-Cookie: sessionId=QpiYzBXNNhiMZQSdWfKiDM; SameSite=None; Secure; HttpOnly; Domain=.mysite.com
(I have also tried Domain=.mysite.com, i.e. with a leading dot, without luck.)
The file API lives at files.api.mysite.com and allows clients to download protected files given the following request header:
Cookie: sessionId=QpiYzBXNNhiMZQSdWfKiDM
The APIs are used by a web app that lives at something.othersite.com. In the browser dev tools, I see that the sign-in response has the cookie in the "Cookies" tab, so I know it's set. And the cookie is sent to other requests against the authentication API. But no cookies are sent in requests to the file API.
As I understand it (e.g. MDN), if Domain is set to mysite.com (or .mysite.com judging by some other sources) then it should also be sent to api.mysite.com and whatever.api.mysite.com. But it's not sent to other subdomains.
What are we doing wrong? How can we get the browser to pass the cookie set by the authentication API on to the file API?
In case it's relevant: Both APIs use CORS, set up to allow the specific host we're using (not wildcard), allow any method, allow any header, allow credentials, and expose a set of headers I don't think is relevant (Set-Cookie isn't included there, but it made no difference when we added it).
The cookie was correct; the problem was caused by how the front-end called the APIs. The front-end uses axios, and the solution was to use the withCredentials option, e.g.:
axios.post(
url,
data,
{ headers: headers,
withCredentials: true }
)

Remove origin header from postman request

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

Set-Cookie for a login system

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.

Setting HTTP headers through Axis2 API

I am using apache axis2 server webservies, Basically I am sending xml response to android client through webservices. Here I need to maintain the session since the services per user basis. I know maintaining session in webservices is bad idea, but cant avoid it.
Actually I need to generate random unique string when user invoke first service from android client, that random string going to be used as session id. This session id, i need to set in http custom header, so that android client can able to get it and can send it subsequent requests as well.
I want to know whether any API is available in axis2 to set custom header information on http headers. Same way I need to read the http header, so that next request I can get the session id from header.
Can anyone advice me regarding this?? Thanks
-Ravi
Dead link on #Martin Dürrmeier's answer, here's a snapshot of the webpage that i've found on web.archive.org : Axis2 - Setting custom HTTP Headers on a response, it helped me.
Here's the lines needed :
MessageContext responseMessageContext =
MessageContext.getCurrentMessageContext().getOperationContext().getMessageContext(
WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
List<Header> headers = new ArrayList<Header>();
headers.add(new Header(HTTPConstants.HEADER_CONTENT_ENCODING, "identity"));
responseMessageContext.setProperty(HTTPConstants.HTTP_HEADERS, headers);