Suppose I make a webpage that includes
<iframe src="http://google.com"/>
and a user browses through that iframe. Does Google see the request made from the server I'm hosting my site on, or from the user's router?
You do NOT load content of iframe source from your server. You just pass that code to the user browser then everything happens on client side. Therefore google will see client ip address and etc.
When one website is called through another domain whether iframe or not, browsers send current domain name to the next target (google.com in your case) with HTTP Referrer data. This is the only way of google.com to understand where the client request google from.
Details : What is the HTTP Referer if the link is clicked in an <iframe>?
I have a page on domain A which loads a webworker script from domain B. The webworker is fetching some PNGs from doman A's server.
In Firefox, the request to get the PNGs contains the cookie for my site (domain A).
In Chrome, it does not include the cookie for my site, and so fails because the request must be coming from a logged in user (which requires the session cookie to be sent in the request).
Which browser is behaving correctly, and can I do anything to make Chrome send the cookie for the current domain from within a webworker?
UPDATE:
I pulled all the files from domain B and hosted them on my server at domain A, so the webworker file is now on the same domain as the site itself, but Chrome still does not send the session cookie with the requests from the web worker.
With regards to the first problem, it looks like the Firefox is incorrect, you shouldn't be able to instantiate a Worker on another domain to quote the spec:
"If the scheme component of worker URL is not "data", and the origin
of worker URL is not the same as the origin specified by the incumbent
settings object, then throw a SecurityError exception and abort these
steps."
With regards to Chrome the Workers run in a separate they work for me and without seeing more code it's hard to answer. But if you visit this demo and break before the postMessage to the worker set document.cookie='test=1' you will see that when the request goes out from the worker it is set.
I have the domain test.com(just as an example), which I have bought from namecheap. I have redirected the domain to http://app-test.rhcloud.com/. However, when entering test.com in my browser I still can see http://app-test.rhcloud.com/ in the browser instead of test.com. Any recommendation how to clean that up?
I appreciate your answer!
You need to use a cname for your application, not a redirect. A redirect just tells the browser, now go to this domain instead. Check out this blog article for the correct way to setup what you are trying to do: https://www.openshift.com/blogs/custom-url-names-for-your-paas-applications-host-forwarding-and-cnames-the-openshift-way
The new Oauth2 authorization process seems to work very well. It took a little time to change my class methods to handle it and the other changes to the API, but I have everything working smoothly now. One small problem I haven't figured out yet is how to pick up the redirect request when the user clicks "Deny" on the 2nd part of the login process. I get the redirect fine when "Allow" is clicked, but I get nothing at all on "Deny." My callback URL is something like ht-btz://com.cloud so according to the documentation, I'm supposed to get something like this:
ht-btz://com.cloud??error=access_denied&error_description=The+user+denied+access+to+your+application
I've tried it with a custom, Python-wrapped IE browser that can monitor redirection, and with a custom local URL protocol handler, and neither gets any request to the callback uri. But both pick up exactly what the documentation says on the approval click.
It's not really a showstopper, since the "Deny" click stops everything anyway. But it would be better to handle things gracefully with the callback request. So is this is bug, or am I missing something?
thanks
Mike
This is a confirmed bug on Box's end with non-HTTPS protocols. We're working on a fix and should have it out sometime this week.
I don't understand: how are webserver and trackers like Google Analytics able to track referrals?
Is it part of HTTP?
Is it some (un)specified behavior of the browsers?
Apparently every time you click on a link on a web page, the original web page is passed along the request.
What is the exact mechanism behind that? Is it specified by some spec?
I've read a few docs and I've played with my own Tomcat server and my own Google Analytics account, but I don't understand how the "magic" happens.
Bonus (totally related) question: if, on my own website (served by Tomcat), I put a link to another site, does the other site see my website as the "referrer" without me doing anything special in Tomcat?
Referer (misspelled in the spec) is an HTTP header. It's a standard header that all major HTTP clients support (though some proxy servers and firewalls can be configured to strip it or mangle it). When you click on a link, your browser sends an HTTP request that contains the page being requested and the page on which the link was found, among other things.
Since this is a client/request header, the server is irrelevant, and yes, clicking a link on a page hosted on your own server would result in that page's URL being sent to the other site's server, though your server may not necessarily be accessible from that other site, depending on your network configuration.
One detail to add to what's already been said about how browsers send it: HTTPS changes the behavior a bit. I am not aware if it's in any spec, but if you jump from HTTPS to HTTP, and if you stay on the same domain or go to different domains, then sometimes the referrer is not sent. I don't know the exact rules, but I've observed this in the wild. If there's some spec or description about this, it would be great.
EDIT: ok, the RFC says plainly:
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
So, if you go from HTTPS page to a HTTP link, referrer info is not sent.
From: http://en.wikipedia.org/wiki/HTTP_referrer
The referrer field is an optional part
of the HTTP request sent by the
browser program to the web server.
From RFC 2616:
The Referer[sic] request-header field
allows the client to specify, for
the server's benefit, the address
(URI) of the resource from which
the Request-URI was obtained (the
"referrer", although the header
field is misspelled.)
If you request a web page using a browser, your browser will sent the HTTP Referer header along with the request.
Your browser passes referrer with each page request.
It seems unusual that JavaScript has access to this as well, but it does.
Yes, the browser sends the previous page in the HTTP headers. This is defined in the HTTP/1.1 spec:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36
The answer to your question is yes, as the browser sends the referer.
"The referrer field is an optional part of the HTTP request sent by the browser program to the web server."
http://en.wikipedia.org/wiki/HTTP_referrer
When you click on a link the browser adds a Referer header to the request. It is part of HTTP. You can read more about it here.