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.
Related
I have a mirror API based app in which i have assigned a custom menu item, clicking on which should insert a new card. I have a bit of problem in doing that. I need to know of ways i can debug this.
Check if the subscription to the glass timeline was successful.
Print out something on console on click of the menu.
Any other way i can detect whether on click of the menu, the callback URL was called or not.
It sounds like you have a problem, but aren't sure how to approach debugging it? A few things to look at and try:
Question 1 re: checking subscriptions
The object returned from the subscriptions.insert should indicate that the subscription is a success. Depending on your language, an exception or error would indicate a problem.
You can also call subscriptions.list to make sure the subscriptions are there and are set to the values you expect. If a user removes authorization for your Glassware, this list will be cleared out.
Some things to remember about the URL used for subscriptions:
It must be an HTTPS URL and cannot use a self-signed certificate
The address must be resolvable from the public internet. "localhost" and local name aliases won't work.
The machine must be accessible from the public internet. Machines with addresses like "192.168.1.10" probably won't be good enough.
Question 2 re: printing when clicked
You need to make sure the subscription is setup correctly and that you have a webapp listening at the address you specified that will handle POST operations at that URL. The method called when that URL is hit is up to you, of course, so you can add logging to it. Language specifics may help here.
Try testing it yourself by going to the URL you specify using your own browser. You should see the log message printed out, at a minimum.
If you want it printed for only the specific menu item, you will need to make sure you can decode the JSON body that is sent as part of the POST and respond based on the operation and id of the menu item.
You should also make sure you return HTTP code 200 as quickly as possible - if you don't, Google's servers may retry for a while or eventually give up if they never get a response.
Update: From the sample code you posted, I noticed that you're either logging at INFO or sending to stdout, which should log to INFO (see https://developers.google.com/appengine/docs/java/#Java_Logging). Are you getting the logging from the doGet() method? This StackOverflow question suggests that appengine doesn't display items logged at INFO unless you change the logging.properties file.
Question 3 re: was it clicked or not?
Depending on the configuration of your web server and app server, there should be logs about what URLs have been hit (as noted by #scarygami in the comments to your question).
You can test it yourself to make sure you can hit the URL and it is logging. Keep in mind, however, the warnings I mentioned above about what makes a valid URL for a Mirror API callback.
Update: From your comment below, it sounds like you are seeing the URL belonging to the TimelineUpdateServlet is being hit, but are not seeing any evidence that the log message in TimelineUpdateServlet.doPost() is being called. What return code is logged? Have you tried calling this URL manually via POST to make sure the URL is going to the servlet you expect?
From the perspective of a wireless router on a wall in a coffee shop, can my computer be uniquely identified via an HTTP request? I think it get's my MAC adress doesn't it?
Next question, from the perspective of a remote server that I send an HTTP request to, can I be uniquely identified? In this case, the server doesn't get my MAC address, but someone else's that is past me, right? What other information could make my HTTP request uniquely identifiable? The IP address doesn't help either, because that would just narrow me down to the coffee shop I'm setting in, right? And I could always move to a different router. I suppose cookies would work here, but we can't guarantee that people won't flush their cookies. How close can we get to unique identifiability? What strategies can be used.
Your best option are HTTP Headers, you can take at this list for some headers already in the wild.
I don't know what you are trying to achieve, but I suppose you want to create an identifier for every user. So you have two options, implement this on router or gateway or on the client side.
Here is the situation, we have a site that is hosted and updated by a third party vendor. I am providing links to additional resources that are hosted on our servers. A client will access the vendor site and click on a link to gain access to our additional resources. To validate that the request came from our third party vendor I need to get the IP address of the vendors server.
My question is, is there a way to get the IP address of the vendors servers using ColdFusion? I can't use the clients IP address, I need the vendor server address the client is using.
You have to work with 3rd party to accomplish this goal, this is for sure.
I can see at least two more or less working approaches here.
(1) Append some kind of protection token to the links. Your vendor generates encrypted string or hash including some information only you two know, so you can decrypt (or generate same hash) and validate it.
Example with hashing:
moment = DateConvert("local2utc", Now());
token = Hash("SecretSaultYouBothKnow" & DateFormat(moment, "yyyy-mm-dd") & TimeFormat(moment, "-HH-mm"));
This token is passed with link and expires quickly to prevent sharing/leaking.
You can generate and validate it on your side.
It's a raw idea and there could be possible problems with validation, plus avoiding invalid links for clients (maybe skip "mm" mask as well).
Encrypted/decrypted string would work similarly. You both just need to now the secret key.
By the way, your vendor could encrypt their server IP address or other identifier for you to check it against your database and maybe apply some other actions.
(2) Your vendor could set up simple web-service for you to validate the incoming links (it could respond with 0/1 or something else simple).
Exact implementation may be different. Again, it could be some token in URL which you send back for validation.
This is similar to solution which Jason suggested: vendor could send the server-to-server request to your server on link click and then relocate to the resource. But this may be complicated because you have to be sure 1st request is already handled when client arrives.
Hope these ideas make sense.
No, there isn't. Not if the request comes directly from the client. If the vendor sends some sort of a message first you can use that to validate. Or if the vendor's server is the one making the request on behalf of the client then you could use CGI.REMOTE_ADDR. But if the vendor is just providing a link to your site, then no, you cannot be assured of the IP of the vendor's server.
The closest you could come is to check the HTTP_REFERER, as Jeremy said above, but that can be spoofed (very easily), so it wouldn't be very secure.
To access the CGI variables available to ColdFusion, you can do something like this:
<cfset ThisIP = CGI.SERVER_NAME>
There are many useful CGI variables available here:
http://www.perlfect.com/articles/cgi_env.shtml
try placing a page on your server that uses the cfhttp tag to fetch:
http://www.dslreports.com/whois
That will give you the IP address of the web server.
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 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.