I have been googling, but haven't found an answer.
I understand pretty well what the cookie scope does in ColdFusion. But I'm not 100% sure about the purpose of the client scope or the differences between it and the cookie scope.
It gets a bit muddy because one of the storage methods for the client scope can be set to cookie.
Can someone supply an example, or use-case, that illustrates what the differences are and when I would use one versus the other?
Cookie scope persists the data as cookies on client's browser. Keep it small as it is sent along Every freaking http request. :)
Client scope can persist the data on DB (or registery on Windows, BAD BAD BAD, but it is the default). It is used often in a clustered env with non-sticky session, where a request might be routed to any server where Session data is not available.
I don't have the link, but you can read more on them in CF Dev Guide.
Related
If you would need to see what Information a Site has on you, based on the Cookie ID that they've stored on your Computer, how exactly would one do that?
You can't.
A cookie is best considered an opaque ticket, passed from the server to the client, for the client to return to the server as a means of storing state, or a reference to server-side persisted state, without the server needing to keep track of it itself.
Granted, some cookies are non-opaque, especially those that are intentionally exposed to Javascript (such as storing client-side preferences), but I'm assuming you're not interested in those.
So there is no way for a HTTP client to peer into a webserver's stored state. That's the point. Otherwise it would be insecure.
Here's a simple demonstration:
[Client] Hi Server. My name is Boris.
[Server] Hi Boris. I have assigned you visitor number 3. I have remembered your name is "Boris" and saved it in my internal database, associated with the number 3. Please refer to yourself as 3 in all future requests.
[Client] Okay, thanks, goodbye.,
(weeks pass)
[Client] Hi Server, remember me? I am visitor 3.
[Server] Yes, hello Boris.
[Client] I am visitor 3. Please remember that my hair is yellow.
[Server] Yes, I have remembered that visitor 3 also has yellow hair.
(weeks pass)
[Client] Hi Server, remember me? I am visitor 3. What color is my hair?
[Server] Your hair is yellow.
(more time passes)
[Client] Hi Server, I am visitor 3. What information do you have stored about me?
[Server] Hi visitor 3. I know your name and your hair color, but I won't tell you because I don't want to. I didn't even have to tell you that I knew those details.
So even though the cookie in this case is merely the number "3", the client has no way of knowing what the server has stored about it.
Unless the site stores things in your cookie, you're probably not able to get much. The cookie often has a userId or sessionId in it that the site uses to look up the information it knows about you. That information is stored in a database that you won't be able to get access to.
Some things you could do:
Open the developer tools in your browser and look at the internet traffic that goes back and forth. You may be able to see some information about yourself there.
Use a tool like Fiddler or BurpSuite to sniff the traffic between your computer and the site in question.
It may be wise to delete your cookies regularly or find a browser plugin like Self-Destructing Cookies if this bothers you.
In RIAs you typically want to maintain some simple state between tabs and reloads but never send it to the server. With IE7 still out there (doesn't support local storage) -- how about cookies with non-existing paths? They will be accessible from JavaScript since they're on the right domain but never sent over the wire unless we do a call using its path.
Are there any caveats?
Such cookies should be possible to set from both the client and server, right?
(I found ppl asking about local storage vs cookies where the main drawback of cookies is they're sent to the server -- "You're wasting bandwidth by sending all the data in each HTTP header." Local Storage vs Cookies)
I'm creating my own (multi threaded) ISAPI based website in C++ and I'm trying to implement correct session management.
The problem is that when a new session should be created, the session is created twice when using subsequent requests in the generated web page.
Here's how it works:
- Client requests http://localhost and sends either no cookie or a cookie with an old session ID in it.
- Server looks at the session cookie and feels that it needs to create a new one because it no longer exists: it prepares a header with a cookie in it with a new session ID and sends the complete header to the client (I tracked this with http live headers plugin in firefox and it is correct). It also prepares some data like the page and and stuff like that (not yet body data, as it is still processing data from the database and stuff like that) and sends what it has back to the client.
- Client should have this new session cookie now, and sees the stylesheet link and immediately sends the stylesheet request http://localhost/css to my server. But... he still does this with the old session ID for some reason, not with the newly received one!
- Server sees this request (with again an no longer existing session id), generates another new session and sends the new session id with a cookie along with the stylesheet data.
So the client has received two session id's now and will from now on keep using the second one as the first one is overwritten, but nevertheless the first page has used the wrong session (or actually, the second page has).
You could say that this is not a problem, but when I start using personalized stylesheets, I will have the wrong stylesheet on the first page and as the page will use AJAX to refresh the content (if available), it is possible that the stylesheet is never reloaded unless the client refreshes.
So, is this a problem that is always there when doing this kind of thing? Will the browser always send an old cookie although it has already received a new one but is still processing the page? Is this a problem that, for example PHP, also has?
Note: before all the discussions start about "use php instead" or something: I am rewriting a website that I had first written in PHP, it became popular, had thousands of (real) visitors every hour and started killing my server (the website doesn't make that kind of money that I can throw lots of servers at it). By writing it in C++, requests take 2ms instead of 200ms in PHP... I can optimize everything. By taking my time to develop this ISAPI correctly, it is safely multi-threaded and can be multi-processed, multi-servered. And most of all, I like the challenge.
Added note: It seems that the problem is only there when an old session exists in the cookies, because when I completely clear all cookies from my browser, and a new one is created and sent back to the client, the subsequent stylesheet request immediately uses the given session id. This seems to be some kind of proof that I'm doing something wrong when an old session id is sent... Should an existing cookie be deleted first? How?
Added note: The cookie is written with an expire-date one year ahead.
I have found out what the problem was, I was in the assumption that setting a cookie without specifying a path would result in making the session work on all paths on that domain.
By using http://foo.bar/home as main page and http://foo.bar/home/css as stylesheet, internally translating that url to ?s1=home and ?s1=home&css=y, I was actually using two different paths according to the browser which did not pass the cookie to the css-request.
For some reason, they actually got together afterwards, I don't fully understand why.
Isn't this silly? Will people not often have a http://foo.bar/index.php and a http://foo.bar/css/style.css.php , just because they use subdirectories to keep their structure clean?
If anyone knows of a way to fix it, to make subpaths also work with the same cookies, let me know, but as I understand it from the definition of cookies, they are stuck within a specific path (although, it seems that if you specifically add a path other than /, it will work on subdirectories as well?)
I'd like to do a little data mining, to see if any of my customers are giving out their username/password.
Q: What info can I get about the PC that the person is on?
Their IP address (presuming it's fairly static)
Their Browser (presuming they're not hacking the cgi scope)
Their screen resolution
Their cookie scope (presuming they have cookies turned on)
What else?
I want to see: "Hey! This person is logging in from three different machines!"
See here (plus comments):
http://www.coldfusionjedi.com/index.cfm/2010/11/5/Ask-a-Jedi-Preventing-logins-from-other-machines
Most of that is in the CGI scope:
<cfdump var="#CGI#">
Exactly what will be in there is determined by which Web server you're using (e.g. IIS, Apache, etc), and will vary from server to server.
Example: CGI.REMOTE_ADDR is one of the variables that might contain a usable IP address of the client.
CGI.HTTP_COOKIE may contain all of the cookies from the browser, URL-encoded. You can also dump the Cookie scope:
<cfdump var="#Cookie#">
To get screen resolution I think you'd need to use a JavaScript or Flash solution - maybe even CSS; I recall something about being able to serve different CSS files based on screen size for mobile devices. Maybe in Modernizr? http://www.modernizr.com/
Does every web request send the browser's cookies?
I'm not talking page views, but a request for an image, .js file, etc.
Update
If a web page has 50 elements, that is 50 requests. Why would it send the SAME cookie(s) for each request, doesn't it cache or know it already has it?
Yes, as long as the URL requested is within the same domain and path defined in the cookie (and all of the other restrictions -- secure, httponly, not expired, etc) hold, then the cookie will be sent for every request.
As others have said, if the cookie's host, path, etc. restrictions are met, it'll be sent, 50 times.
But you also asked why: because cookies are an HTTP feature, and HTTP is stateless. HTTP is designed to work without the server storing any state between requests.
In fact, the server doesn't have a solid way of recognizing which user is sending a given request; there could be a thousand users behind a single web proxy (and thus IP address). If the cookies were not sent every request, the server would have no way to know which user is requesting whatever resource.
Finally, the browser has no clue if the server needs the cookies or not, it just knows the server instructed it to send the cookie for any request to foo.com, so it does so. Sometimes images need them (e.g., dynamically-generated per-user), sometimes not, but the browser can't tell.
Yes. Every request sends the cookies that belong to the same domain. They're not cached as HTTP is stateless, what means every request must be enough for the server to figure out what to do with it. Say you have images that are only accessible by certain users; you must send your auth cookie with every one of those 50 requests, so the server knows it's you and not someone else, or a guest, among the pool of requests it's getting.
Having said that, cookies might not be sent given other restrictions mentioned in the other responses, such as HTTPS setting, path or domain. Especially there, an important thing to notice: cookies are not shared between domains. That helps with reducing the size of HTTP calls for static files, such as the images and scripts you mentioned.
Example: you have 4 cookies at www.stackoverflow.com; if you make a request to www.stackoverflow.com/images/logo.png, all those 4 cookies will be sent.
However, if you request stackoverflow.com/images/logo.png (notice the subdomain change) or images.stackoverflow.com/logo.png, those 4 cookies won't be present - but maybe those related to these domains will.
You can read more about cookies and images requesting, for example, at this StackOverflow Blog Post.
No. Not every request sends the cookies. It depends on the cookie configuration and client-server connection.
For example, if your cookie's secure option is set to true then it must be transmitted over a secure HTTPS connection. Means when you see that website with HTTP protocol then these cookies won't be sent by browsers as the secure flag is true.
3 years have passed
There's another reason why a browser wouldn't send cookies. You can add a crossOrigin attribute to your <script> tag, and the value to "anonymous". This will prevent cookies to be sent to the destination server. 99.9% of the time, your javascripts are static files, and you don't generate that js code based on the request's cookies. If you have 1KB of cookies, and you have 200 resources on your page, then your user is uploading 200KB, and that might take some time on 3G and have zero effect on the result page. Visit HTML attribute: crossorigin for reference.
Cookie has a "path" property. If "path=/" , the answer is Yes.
I know this is an old thread. But I've just noticed that most browsers won't sent cookies for a domain if you add a trailing dot. For example http://example.com. won't receive cookies set for .example.com. Apache on the other hand treats them as the same host. I find this useful to make cross domain tracking more difficult for external resources I include, but you could also use it for performance reasons. Note this brakes validation of https certificates. I've run a few tests using browsershots and my own devices. The hack works on almost all browsers except for safari (mobile and desktop), which will include cookies in the request.
Short answer is Yes. The below lines are from the JS documentation
Cookies were once used for general client-side storage. While this was legitimate when they were the only way to store data on the client, it is now recommended to use modern storage APIs. Cookies are sent with every request, so they can worsen performance (especially for mobile data connections).