Is there any case where the browser is sending an HTTP request to a server but does not attach cookies associated with that domain to the request? If so, what are the cases?
Cookies are set by the server first, or are set by a javascript that is executed in a page from that domain. So every cookie you get, it a cookie you have set earlier.
Normal cookies are sent to the server with each request, Ajax as well as regular page loads and posted data. There are some new features like offline storage that is implemented by more and more browsers, but those features are not cookies.
A cookie can have a domain and path associated with it, thus limiting which resources the cookies are sent to.
document.cookie = 'name=value; expires=' + date.toGMTString() + '; path=/myFolder; domain=myDomain';
Yes.
Chrome (as of version 25) does not include cookies in favicon requests. Also, it is apparently standard for other browsers to not share cookies between the favicon requests and other requests.
Related
I have a web server which returns 200 OK with a bunch of set-cookies, and an HTML page which loads a bunch of scripts from the same server.
However, the subsequent loads that was spawned from that HTML page submits a different cookie on their HTTP request headers.
What could be causing that? Surely there's some policy I'm missing out on, but I don't see why it works on some pages and not others?
I'm using chrome as the browser, but this behavior also happened from iOS, so I'm guessing it's not browser specific.
So after a lot more reading and troubleshooting, it turns out that when you don't set a cookie path, it'll default to whatever path the original request set-cookie was sent to. And because my resource paths had a different path, the cookie was not sent.
Adding Path=/ fixed it for my issue. Of course, if you don't want your cookie to be accessible to all pages this is bad, but my web-server requires requests to come with cookies because they are sensitive data (for security reasons).
I am trying to work out how cookies are being set on a website, I have scoured the page source and can see how most of them are being generated.
However, there is one cookie that appears on page load that I can't track down.
Is it possible that a cookie is being set when an image is being requested from a remote server? If so, can I inspect that http request response with a tool to find out if it contains the cookie?
Any HTTP-Request can set a cookie, if the server says so.
Cookies are set using the Set-Cookie HTTP header, sent in an HTTP response from the web server.
https://en.wikipedia.org/wiki/HTTP_cookie#Setting_a_cookie
A request for an image is basically the same as a request for a html page. It uses the same request/response structure. So yes you can set a cookie on an image request.
The request/response can be seen in most modern browsers. In FireFox there is under tools -> Web Developer -> Network a tool that shows the requests/responses from all calls being made on a page. Opera and Chrome have similar functionality.
I have a cookie which is sent from the client which is used as part of my MVC web service, however now that I have integrated a hub into this application the hub doesnt get sent the cookie, whereas the mvc app does.
Now after reading other similar questions (not that there are many) the cookies domain seems to be to blame, or the path is not set.
Currently my system has 2 web apps, the ui and service. In my dev environment it is like so:
Service
http://localhost:23456/<some route>
UI
http://localhost:34567/<some route>
So in the above example, the ui will send a query to the service, getting an authorisation cookie on the response, which is used elsewhere.
In this example the cookie domain from the service is localhost, as from what I have read and seen on other questions there is no need for a port, it will automatically just allow all ports.
Are HTTP cookies port specific?
SignalR connection request does not send cookies
So it would appear to me that the cookie above has correct domain, and the path is set to /, so it should work. However it doesn't send them in the request from javascript.
My request is a CORS request so I am not sure if there are any quirks around that but all normal jquery ajax calls make it to the server fine with the cookies, any ideas?
OH also my cookies are httponly as well, not sure if this makes a difference...
== Edit ==
Have tried to rule out some stuff, have turned off httponly and it still refuses to send the cookies to the server, I have also noticed a few outstanding cookie issues which mention adding the following code in somewhere to make ajax behave a certain way:
$.ajax({
xhrFields: {withCredentials: true}
})
Tried using that and still no luck, so I am out of ideas.
I raised an issue as there is an underlying issue with < version 2 beta of SignalR relating to CORS and cookies.
https://github.com/SignalR/SignalR/issues/2318
However you can manually fix this issue by appending:
xhrFields: {withCredentials: true}
to all ajax requests within the jquery.signalr-*.js, this will then send cookies over CORS, although I do not know if this has any adverse effects on older browsers or IE.
I have a website with a login form in https which sets a session id in a cookie. For some reasons, the rest of the webpage is a cgi-script from http. However, when accessing the cookie from http, it sometimes work, sometimes not, although I can clearly see the cookie is set to correct session id in the browser. I have not yet discovered a pattern. Am I missing something?
https://mypage.com/secure/login.php
http://mypage.com/cgi-bin/script
I set the cookie path to "/", which should do the trick, right? Domain is set to ".mypage.com". Secure only is false, http only false.
Tested with Firefox and Chromium.
Regards
Olle
I would like to load cookies everytime and everywhere in my website because when my RoR application receives and accepts an "external" HTTP request (ex: REST API), cookies are not loaded (see RFC2109). So their values are inaccessible.
Cookies are accessible only when the HTTP request is made "internally" in my application.
new_cookies = {"Cookie" => "mycookie=1234;myothercookie=4567"}
Net::HTTP.get( URI.parse( http: //app1.website.com/users ), new_cookies)
All browsers will automatically send any cookies you set from your domain, you can check them simply by calling request.cookies from any controller method. It doesn't matter if the request was initiated from within your application (such as a 302 redirect) or not.
I just tried this with Firecookie:
Created a cookie "mycoolcookie" for the domain ".stackoverflow.com"
Went to stackoverflow.com, firebug showed that the cookie was sent in the request header.
Went to meta.stackoverflow.com, firebug showed that the cookie was sent in the request header.
Went to chat.stackoverflow.com, firebug showed that the cookie was sent in the request header.
A cookie is sent automatically by the browser, the server can never request for a cookie to be sent to it.
REST APIs are generally stateless, therefore you should avoid the use of server-side sessions or client-side cookies. If you want to indicate that a user only grabs resources belonging to them, use the Rails nested resources approach, that results in a call like:
http://abc.com/user/user001/books
For all books that belong to user001.
If you are looking to implement security, first you have to use HTTPS instead of HTTP. For the actual implementation you can use Basic Authentication and set the username/password in the request header or you can use something like OAuth which sets up a token for the user that they pass in with each request.