I am working with an MVC server with IIS express on port x.
I run my client code using express server on port y, and send my requests for data to the server on localhost:x
The issue here is that the SessionId cookie is not sent back to the server on every request due to CORS.
I read that the cookie will not be sent to a different domain in case the cookie is not set to SameSite->none but in order to set it to None you also need to set it as Secure as i read from here https://web.dev/samesite-cookies-explained/
Is there an alternative in case I want to work with HTTP and i want the client to send the cookies to the server
Well there are 2 possible solutions for this matter:
You can set the cookie as secure + SameSite->None to make the browser automatically send the cookies for every request
You can tell the browser to send the cookies yourself on each request via:
Ajax
Fetch API
Related
Since XSRF validation involves matching of cookie/token sent in the UI request with the request header as part of that same request, what are the options for testing locally?
So assuming I run my UI locally and I am pointed to server hosted in a different place, the cookie would never be able to read on localhost (since it is a different host). What is the best-practice in this case - is it adding logic on server to identify the Origin and bypassing the check if Origin is localhost ?
What I usually do in such a case is to use /etc/hosts and use a subdomain for my code running locally. E.g. the UI is run on www.example.com and the server is on api.example.com, then in my hosts file I point www.example.com to localhost.
If the cookies are not samesite cookies and the server has proper CORS settings, then in fact it shouldn't be a problem using them from localhost. Your UI won't have access to them, but the browser should send them together with any request to the server. (CORS should allow credentials and the http client of your UI should use something like a withCredentials: true flag)
I am trying to open a websocket to a server with kerberos authentication, error during handshake occurs (error code : 400) ;
i saw it's not possible to send credentials through web socket and what i have to do is to set the username and password through web socket cookie and the server will read them.
So how can i set cookies for web socket ?
thank you,
It depends on the browser. You may implement handling cookies if they arrive with the initial HTTP request to initiate a WebSocket connection, but if you can't require your users to, say, use Safari, which sends cookies with WebSocket open requests, and not Chrome, which does not, you'll probably have to implement a mechanism for the client to send in the session identifier in-band.
One simple way to achieve this is for the client code to send in the session identifier as the first message in response to the open event, and the server code to interpret the first incoming message's content as the session cookie, to set up the appropriate privilege context (or perhaps close the connection if the cookie is unknown or otherwise grants no privileges to its bearer).
Alternatively, if your WebSocket protocol has some sort of structured message infrastructure, you may define a specific message type for passing a session cookie to the server, as well as a matching response type for the server to let the client know what it thinks of the cookie.
It may be tempting to pass the session cookie in an URI parameter, as in ws://example.com/service?SESSION=123456. This can be adequate in prototyping, but it is probably ill-advised in production, since session cookies should generally be treated as more sensitive than it is customary to treat the list of URIs requested from a web server. Passing session cookies in such a way can work in the short term, but may increase the risk of their accidental exposure via, say, careless analytics techniques. This concern could in some other context be alleviated by passing the sensitive identifier in the body of the request (for example, as a so-called POST parameter), but WebSocket open requests can not have a non-empty body.
You can set cookies for a webSocket connection the same way you set regular cookies, with document.cookie = xxxx. All webSocket connections start with an HTTP request (with an upgrade header on it) and the cookies for the domain you are connecting to will be sent with that initial HTTP request to open the webSocket.
So, as long as you are doing the webSocket connection to the same domain as your web page, then you can just set a cookie for that web page and it will be sent with the webSocket connection request. And, as with other cookies, you set a cookie using document.cookie as described here on MDN.
In a javascript single page application, on first request of the user to the front-end, a cookie is set with Node JS Express.
Credentials are included to requests by adding the "credentials: include" option to Fetch API.
The first render is server-side with React server side rendering.
I can see the cookie in developer tools. It is sent on every request to the front-end, but not to the backend.
Front-end and backend are both node servers. In development they are on differents ports of localhost, (also tried setting a domain in hosts file but no difference). In staging the api server is on a subdomain of the front-server domain. Neither works.
Can they share the same cookie or should I create one cookie for each? I can't seem to set the cookie for the requests to the backend, either because different port in dev or different subdomain in staging.
Ok so I think I figured it out.
Cookies were sent on some requests but not on others. Checking the request method, turns out cookies are not sent when method type is "OPTIONS", which is preflight, and apparently this is normal.
The workaround is to avoid checking cookies if request method is OPTIONS and just send a 200 empty response in this case, so that the real request can proceed, during which cookies will be sent.
Storing client session data as a cookie seems more secure than anything else, but I am not sure how to send/include the front-end cookie in a CORS AJAX request. I know I should set withCredentials to true on XmlHttpRequest, but other than that, I am not sure how the cookie actually gets sent to the server?
So on the Node.js server, I would send the cookie to the browser with
function(req,res,next){
res.cookie('lectal-cookie', someEncryptedToken, {maxAge:'12h'});
}
on the client (browser), I assume that cookie is automatically stored somewhere-
but how do I include the cookie in a cross-origin AJAX request? Do I send it as a header or can I send it as a cookie or both?
Will using withCredentials=true automatically include all the browser cookies in the AJAX request?
Is it possible to get a session from a server and pass that session cookie to another ip so that one can use it to communicate with the server that issued that session?
session server -> my backend server 1: getting session cookie
my backend server 1 -> my backend server 2: passing session cookie
session server <-> my backend server 2: communicating directly with session server without the middle man.
I'm using CouchDB and Node.js/Javascript.
I tried to send the set-cookie header received from session server (couchdb) to backend server 2 and it did set the session cookie in the browser. But when making requests to couchdb it didn't send that cookie along. I think it's because of it has to be the same ip that it got the session from, in this case, the server 1.
How do I make it work?
Cookies are based on domains, so the browser will only send the cookie back to the domain it was set on.
You get the client to send a request to the second server with data allowing the server to create a new cookie. Not sure what kind of security you need.