As identified in C # where this is requested a specific web page, I wonder if the request comes from an image <img src="http://www.mydomain.com/default.aspx?n=123" /> or if the request is directly through an http browser, for example when the client is actually accessing the page via a browser sample: http://www.mydomain.com/default.aspx?n=123
See Finding the referring url that brought a user to my site.
You'll probably get more answers if you tag your question with ASP.NET.
No, it's not completely reliable. HTTP is in large part a cooperative protocol. That is, there are fields there that browsers can use to identify themselves and tell you where they're coming from, but nothing forces them to do it. The sad truth, unbelievable as it may seem, is that people might lie to you. They might say they're viewing your image from your Web page, when they really aren't. Or their browser might not tell you that it's viewing the image from your Web page. In general, the UrlReferrer thing works, but it can be defeated. Just as the browser identification string can be spoofed. We do the best that we can, and call it good enough.
I would expect the Request.UrlReferrer to be null when the image src makes the request.
Related
Please Note: This question is not related directly to Server-side detection that a page is shown inside an IFrame, as I'm showing you an instance where it would appear that the guys at MDN (Mozilla Developer Network) are already detecting that content is being delivered to an iframe, although, if you read through this, I discuss the possibility that this isn't server-side related at all; it might be some sort of "rights" issue declared some how or in some way I don't know about. The point is to understand how something already existing works.
First of all, I do not desire to rip off MDN (Mozilla Developer Network) content as my own. I'm asking this because I'm truly puzzled by it. The guys at MDN seem to have pulled of a nice trick, and I'd like to know it, but maybe its simpler than I realized.
The code is only:
<iframe src="https://developer.mozilla.org/en-US/docs/HTML/HTML5"></iframe>
Take, for example, this fiddle:
http://jsfiddle.net/jfcox/D3UNZ/
Do you notice how there's no content in the iframe? There doesn't appear to be any content related to the request on the Chrome network tab.
I assure you, that'd work on a "normal" website, like example.org. see http://jsfiddle.net/jfcox/nPwcu/
So, I ask, what is it that they are doing to detect that a request is being made from an iframe?
Is there some Browser-Fu I don't know about? Oddly enough, that might be the case. From IE9.
To help protect the security of information you enter into this
website, the publisher of this content does not allow it to be
displayed in a frame.
Wow! Ok, so maybe it's not server-side, maybe it's all Browser-Fu. Even so, how does IE9 and these other browsers know what I don't know? What do I need to look up to learn about this?
I have my own suspicions, namely that there's some file at the root of the website like crossdomain.xml for flash that defines permissions about content usage or whatever, but I still wouldn't even know where to start if that's the case.
Turns out, it's a pretty simple copy protection. All you need to do is set a response header.
https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options
https://datatracker.ietf.org/doc/html/draft-ietf-websec-x-frame-options-00
Yes, "frame", instead of "iframe".
:eyeroll:
I suppose the name makes sense, considering the possibility somebody could still attempt to use old HTML 4 frame tags for whatever purpose, and I would expect most browser/DOM engines have baked-in support of frame tags given HTML history. Netscape created/supported frames as early as version 2.0 and iframe was a later, purely-Microsoft invention that found wide adoption, IIRC.
i heard that , if your asp.net page is inside a iframe, and u want to get the parent url, you can achieve this by using the referrer?
i tested is okay, and found that the window parent url will included in the referrer when called the iframe content
Request.UrlReferrer.ToString();
Assume that i can only use server side to achieve
I just want to ask is that way safe?
Any chance to lost the referrer url in this case
The browser is not guaranteed to send the referer. It's all up to the browser/configuration/extensions/proxies and whatnot between the request and your server.
If the user navigates to a different page within the iframe, the referer will point to whatever the user came from.
All in all, never use the referer for any logic that may fail if it's not there or if it has an unexpected value.
You can do this but it is not entirely in ASP.Net.
You would have to get the referrer from Javascript and pass that to the iFrame.
One of the 2 following calls would be what you are looking for.
top.document.referrer
or
parent.document.referrer
I have been searching around for a way to simply request webpages with HTML5. Specifically, I want to do an HTTP(S) request to a different site. It sounds like this is not possible at first due to obvious security reasons, but I have been told this is possible (maybe with WebSockets?).
I don't want to use iframes, unless there is a way to make it so the external site being requested does not know that it is being requested through an iframe.
I've been having a really difficult time finding this information. All I want to do is load a webpage, and display it.
Does anyone have some code they could share, or some suggestions?
Thanks.
Sounds like you are trying to to circumvent Same Origin Policy. Don't do that :)
If it is just the request you want (and nothing else), there are a number of ways to do it, namely with new Image in JavaScript or iframe. The site will know it is in an iframe by checking top.location.href != window.location.href.
funneling all your requests through a proxy might be a solution - the client addresses only the proxy and the actual url to retrieve would be a query string parameter.
best regards, carsten
Many browsers in Japan (EZWeb, i-mode, etc) don't allow meta refresh, and in fact, they may display warning messages such as "This page uses newer technology and cannot be displayed" in place of your webpage.
How can I tell if a mobile browser does not support meta-refreshing so that I can take different action in those cases?
Thanks
The best option for something like this is to display a link on the page with the meta-refresh. The traditional "click here if the page doesn't redirect you in 5 seconds" kind of thing. That's what has been done for years in the PC realm.
You should also consider an HTTP 304 with the Location: header if you are just redirecting.
If instead you want a page to reload after a specific amount of time, then you are stuck. Without JavaScript, there is no other method you can use to automatically do this.
Without JavaScript you're really limited to User Agent sniffing. To provide the best experience I would recommend use known UA strings to only send the meta-refresh to browsers you know can handle it and for those that you don't know send a plain HTML response that has a link for users to click on to do the refresh.
How to login without leaving RP by showing the OP login window in iframe ?
I am using Openid Provider for the login in my Website.
how to implement the login window inside the iframe.
Using an iframe is hugely frowned upon, since the user will be entering their credentials on a page that looks like it is your RP but is supposedly their OP instead. It teaches users to be phished.
If you're going to use an iframe anyway, very little special work has to be done. There are a few approaches you can take though. If you're taking the OpenID Identifier from the user on the page and will display an iframe based on the user input, then the easiest way is probably to use JavaScript when the user clicks "Login" to create an iframe and direct it at http://yoursite.com/redirect.aspx?openid=userSuppliedIdentifier. That page will perform OpenID discovery on the identifier and do the standard redirect to the OP, which will be limited to the iframe since that is where the request came from. The openid.return_to that you send to the OP will have to be to a special page that knows how to "pop out" of the iframe back into your main window. It's really a very similar flow to the popup window approach which I point you to a demo to below, but instead of a popup, you do it in an iframe.
Rather than an iframe, the recommended way if you don't want to send the users away momentarily from your site, is to use a popup window. Just one such example of this is DotNetOpenAuth's ajax login sample, but there are other ways to do it. It's always complicated to get it working across browsers and working securely. We'd need to know what web platform you're using (ASP.NET, PHP, Perl, Python, etc.) before going much further.
(In response to Andrew Arnott's response) I'm bothered that popups are considered the norm for redirects. It's true that Facebook has adopted this approach, but I don't think it's the final solution. From a UI/UX pov in other applications, we've tried to move away from popup windows in favor of inline types of user experience. (popup ads, for instance are extremely annoying) Popups in general are just aggravating. Hence javascript library third-party widgets such as thickbox/lightbox/shadowbox. These solutions allow for iframe loaded content.
Plaxo and Google provided an experiment showing something like a 92% return rate for users who signed in with a two click OpenID process, so the question isn't about return rate, and yes popups can work in that scenario, however...
What I think hasn't been solved is adoption rate, and this comes down to basic usability and user experience, and what most engineers seem to be missing is the fact that users are completely driven off by popups.
It's true that phishing is a problem, but I think the onus and burden for better security lies with the developer on this one, and not the user. For this reason, I still think an inline experience is best, and, unfortunately, iframes are the only methodology currently employable. There are solutions, however, to prevent phishing.
I see that you are discussing usage of iframes for OP authentication. Have you considered the fact that clickjacking becomes possible when using iframes? In fact, many OPs do not allow their pages to be included in an iframe, e.g. VeriSign, Yahoo, myOpenID, etc. They break out of iframes using the HTTP header X-FRAME-OPTIONS, or JavaScript like this:
if (top.location != location) {
top.location = self.location;
}
Take a look at http://ajaxian.com/archives/busting-framebusters-clickjacking-is-still-a-big-issue for more information.