I am working on a web page which has an iframe and I am loading an external site in the iframe. The page works fine in IE6, FF etc but in IE7 all I see is a blank page.
I found that this is due to the phishing filter in IE7. The phishing filter will not be able to check the web page inside the iframe so it will not be rendered properly. Have you faced this issue before? How can I resolve it?
Edit: Okay. After seeing first two answers I think I should give some more explanation to this. The page is for payment processing and I am loading a page (of a 3rd party company) which asks for credit card information. Right after entering details and pressing continue the iframe goes blank. After much investigation we found that IE7 does not accept 3rd party cookies (when page loaded in iframe). It is something to do with the security settings. Some articles in the internet say that I can bypass the phishing filter. How can I do it?
If you are using ASP then add this code
Response.AddHeader "p3p", "CP=" & chr(34) & "CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR" & chr(34)
in all the pages which are loaded in the iframe
IE7 does not accept 3rd party cookies (when page loaded in iframe).
It can do, it depends on the options that are set. Especially if the privacy level has been turned up, the third party must provide a P3P policy file to ensure IE that it's not going to be naughty. (As a privacy measure this is a bit of a dead loss IMO, but we're stuck with it.)
I am loading a page (of a 3rd party company) which asks for credit card information.
Whoah! Don't do that. The user won't be able to see from the address bar that it's the correct site URL and it's properly encrypted with SSL. You're effectively asking your customers to trust an unknown site and connection.
Lose the iframe. Most payment processors will have options to style your payment pages to match your site, and return the user to your site when they're done.
Have you set the IFRAME attribute WIDTH? I've read about this before and in those occasions had to do with the 'WIDTH' attribute.
So instead of using the WIDTH attribute of the IFRAME, you could use the STYLE attribute instead:
<IFRAME SRC='yourpage.html' STYLE='width:100%;'></IFRAME>
[UPDATE]
In my above example I've used a %-age to declare the width of the IFRAME. You could try to declare it in pixels instead of percentage, e.g.:
<IFRAME SRC='yourpage.html' STYLE='width:600px;'></IFRAME>
Then again, this could not be the problem in your case, but please do provide more information.
Finally I found the solution for this!
It can be solved by adding the p3p header to the webpage. This tells the browser that the cookie created by the pages in the iframe are OK for user's privacy. The header has to be added to all the pages loaded in the iframe.
Below are some of the links which shows how this can be achieved in different scripting languages (PHP, ASP.net , JSP etc).
http://adamyoung.net/IE-Blocking-iFrame-Cookies
http://adamyoung.net/IE-Blocking-iFrame-Cookies
http://admon.org/node/99
Note: I dint use this solution for security and compliance reasons. Thanks Bobince
Perhaps you are using a title tag like <TITLE/>
Related
I've been googling and looking at various options but could not seem to be able to find a perfect solution that works in what I'm attempting...so needing some help here.
The situation/environment that I have is the following:
Parent page (which has the iframe) - is on a different domain, and the only control I have is a portion of the body tag, where it is updated via an admin console using html/WYSIWG editor. No access to head tag or even hosting jscript in their domain.
Child page (iframe) - is hosted in our domain, and we have full control.
The parent site is actually 3rd party online stores where we have products there, and we want to put in common information that we can control on our end without having to edit each individual product listing one by one.
I've tried alot of options found but it does not seem to work as either they need to include in js file or access to the head tag in the parent page.
So wondering if there are any other options that can help us on this?
I'm afraid you need access to JavaScript on both domains to do this.
Could you get the 3rd online store to host a small JS library that all their clients could then use to solve this problem? I work on a project that allows third parties to add in iFrames and produced this little project for just this reason. When any one say they want to be able have their iFrame resize to content, we point to the iFrame js file and say include this on your page.
https://github.com/davidjbradshaw/iframe-resizer
Sorry, that's not quite the answer your after, but trying asking the store to support this and they might be open to the idea, as I expect others have the same issue with their site.
I have a website that I created for the company I work at. This site is on a subdomain and is brought in as an iframe within another company's retail site, as we offer services under them. Is there a good way to track this with google analytics? I've never tracked a subdomain before, let alone in an iframe.
I've created a test analytics account, and added the top level domain, but I only put the tracking code on the pages for the subdomain that I created the site on. Will this even give me any information? and if that part of it works, is the information from an iframe setup accurate? I know from a design standpoint an iframe is kind of off in it's own world within a world, but does anyone have any experience on how google sees a site like that?
I've searched the forums and anywhere else i could think of, and they have bits of info on subdomains, practically nothing on iframes, and nothing combining the two. I have no access to adding any tracking code to the partner company's retail site either.
If your iframe hosted content is not on the same domain as the parent page (which I'm going to assume is not, based on the context of your question), then google will report the page name as the URL of the iframe, not the parent page.
GA code has a way to override the default page name, however, you cannot retrieve the parent URL in this case, because this is considered cross-site scripting (XSS).
The only way to get info about the parent page in this case is for whoever has control over the parent page that has the iframe tag, to pass the parent URL to the iframe by adding a query string parameter to the iframe src="..." attribute (also, same thing for any other info you want to pass to the iframe page). Then you can write some javascript to retrieve those values from the URL and pop whatever you want, including overriding the default reported page name (which you would do by setting the optional 2nd param to your _trackPageview call).
If the iframe content IS on the same domain (even if it is a subdomain of the parent page), then you can access the parent page properties using parent.window.whatever instead window.whatever.
Well, from what I understand, you have a page that will be inserted inside an iframe to a second page, but we need to know if the page that will host the iframe is the same domain as the calling page:
If the page called by the iframe in the same domain of the calling page:
In this case, you can insert the block of JavaScript Google Analytics, as both the iframe on the main page, and we have the measurement data from the main site, the iframe.
If the page that calls the iframe belongs to a different domain:
Some of the features that are measured are in frames within the site. These iframes indicate the domain, for example, site.com.br. Whenever a page in one domain has a frame to a different domain prevents the browser cookies that are stored inside the Iframe, which in the case would prevent the measurement.
Cookies are nothing more than small text files that are stored by your browser on the machine. Most of our cookies are session cookies that are automatically deleted from your hard disk in the closing of the window. Persistent cookies also are used by websites to facilitate identification of your computer in the next visit you make to the site. Inactivation of the cookies can be made in your browser however, this will preclude all the functions available on the site.
To allow the recording of cookies should add P3P headers in HTTP server that serves pages. This header causes no change in display mode or operation of the pages. Just instruct your browser to allow to record cookies of third, however, it has a bigger role in Internet Explorer. If you do not set, you can receive data from other browsers (Google Chrome, Firefox, Opera, etc. ..), but Internet Explorer still has a widespread use of the mass of the population.
Imagine that we have four distinct domains:
www.site1.com
www.site2.com
www.site3.com
www.site4.com
These four pages will receive the iframe tag:
<iframe Src="http://www.meusite.com.br/anuncio.php">
The anuncio.php page need to have a call header p3p for accept the third party cookies.
To add the header p3p use the code below (should be added to all pages that belong to the same domain)
ASP.Net
HttpContext.Current.Response.AddHeader ("p3p", "CP = \" "PSA CONE NOI ONL OUR BUS \" "")
PHP
header ('P3P: CP = "NOI PSA CONE ONL OUR BUS"');
JSP
response.setHeader ("P3P", "CP =" NOI PSA CONE ONL OUR BUS '")
ColdFusion
<cfheader name="P3P" value="CP='PSA CONo OUR ONL NOI BUS'" />
I hope to have helped:)
I have an odd error with an ASP.NET web page (ASP.NET 2.0, C#). For several users at one customer location, on one part of one page, HTML content and attributes are being stripped out. So, something that should look like this:
<p class="adminmainlink">
Add or edit resources
<script type="text/javascript">
var hb526 = new HelpBalloon(
{
title: '',
content: 'Add or edit downloadable file, web links, and text resources associated with a course.'
}
);
</script>
</p>
In the users' source code looks like this:
<p><a></a><script></script></p>
Not only is the content of the HTML tags disappearing, but also the attributes of the tags (the "class" value for the "p" tag, the "href" from the "a" tag).
Other areas of the same page are being rendered fine, with no changes to the HTML. The HTML isn't being generated by a code-behind page -- it's just plain text in the .aspx page. The area that is rendering correctly is in the .master page; the problem area is inside an asp:Content tag.
This error is only happening on one page of the application. Other, very similar pages that use the same .master page are unaffected. I am not able to reproduce this error outside of the client's facility, even when logging in to the client's account. The client is using IE 6 -- we have tested on that, and all is OK. No other customers are reporting a similar problem.
Maybe it's a content blocker or firewall issue at the client's location? Maybe the script is causing the content filtering (other pages use the same script and they display fine, however)?
If it's a code problem, it would seem to affect only the area inside the asp:Content control that is dropping into the .master page. Has anyone seen something like this before? What part of the ASP.NET page life cycle would eliminate attributes and tag content from hard-coded HTML? I could see weirdness happening with a control, but with regular HTML?
Many thanks for your thoughts and opinions!
Are the users using Firefox with AdBlock or some other ad blocking software? I've had strange behaviors in our internal application where certain content was being mysteriously removed, and it turned out it was because a liberal filter was applied, blocking out the word "ad." I noticed "ad_resourcewizard.aspx" was contained in your link. You should have the customers at that location try a different browser or disable their ad blocking software in case it's hooked into their networking software (a plugin for their security suite, for example).
Check whether they have any internet security software installed, and if so, try disabling it.
I know we had an issue with one of the versions of Norton Internet Security, which was stripping scripts out of our CMS pages for one particular client.
This is a follow up to my previous question: Problem passing parameters via Iframe in IE. Which was never solved.
Here's the core of it:
I'm trying to execute an HTTP GET from
my website to another website that is
brought in via iframe.
On Firefox, you can see in the source
that the correct url is in the iframe
src along with it's correct
parameters-- and it works.
On IE, you can see in the source that
the correct url is in the iframe src
along with it's correct parameters--
and it doesn't work...
Is there something about IE that
doesn't let you pass parameters
through an iframe in the querystring?
I've tried refreshing the iframe in
IE, I've tried refreshing my page &
the iframe in IE, and I've tried
copying the url and re-pasting it into
the iframe src (forcing it to refresh
as if I just entered it into the
address bar for that iframe window).
Still no luck!
Anyone know why this is happening, or
have any suggestions to try to get
around this?
As for the code, all it's doing is creating
the src from the backend code on page
load and setting the src attribute
from the back end...
//Backend code to set src
mainIframe.Attributes["src"] = srcWeJustCreated;
//Front end iframe code
<iframe id="mainIframe" runat="server" />
I've made a temporary account for you to login and see exactly what I mean. That way you can use firebug or any of your other debugging techniques to figure out why this isn't working rather than having me try to explain what's going on.
EDIT: Changed the account credentials. Please use this one instead
Username: matt
Password: globalbuying
Please follow this link to get to the login page. One you login with the above credentials it will take you to the main backend page. Click the image on the left that says "Vacations", that will take to you a page with the iframe and will execute the Http Get from there.
If you need more details on what's going on in the behind code, etc., let me know and I'll post them.
Thanks,
Matt
After working my way through the HTTP requests with Fiddler2, comparing different browsers, I found that IE makes the request just fine, but fails to set any cookies in the iframe.
I also noticed that if I open that framed page by itself it does work. Even more so, after logging out again there, the iframed version works too. That's because it then already has a session cookie and the iframe no longer needs to set it.
It turns out that this is a known security restriction: IE blocks cookies in iframes. But this can be overcome with the use of the Platform for Privacy Preferences (P3P).
Here are a few links that should help you fix the problem. Starting off with another (answered) question on StackOverflow:
Cookie blocked/not saved in IFRAME in Internet Explorer
Privacy in Internet Explorer 6
IE Blocking iFrame Cookies
The example page you provided is working for me in IE8. The iframe is not as tall as in chrome, but it does have the correct page in it.
As an aside, please note that passing logon credentials via the query string is extremely unsecure and open to various exploits.
It seems that the ampersands in the iframe's URL are HTML-encoded (&).
I think that might cause IE to choke on identifying the param names. Does the problem still occur if you use plain ampersands in the URL?
If the encoding on the src attribute is happening implicitly, you might want to consider using a Literal control for testing purposes and set its Text property to the entire iframe tag to avoid any unwanted encoding.
We're developing a web shop, and process payments with a third party UI.
We have chosen to show the payment UI inside an iframe inside out check-out page, even though (we now realize), the payment solution provider recommend using a top-level window.
Now what happens is that in IE7/IE8, the payment UI loses session state on the first postback (inside the iframe), while in Firefox, it works just fine. We observe that the payment UI is developed using ASP.NET.
I was under the impression that as far as the server is concerned, there is no difference between being referenced from an iframe versus from a top-level window, but clearly there is.
Does anyone have a clue? What does an iframe do that could possibly make a difference to the payment server, causing it to lose session state?
Could it (it suddenly dawns on me) be differences in cookie handling? Stricter security perhaps?
Probably caused by this:
Internet Explorer 6 introduced support for the Platform for Privacy Preferences (P3P) Project. The P3P standard notes that if a FRAMESET or a parent window references another site inside a FRAME or inside a child window, the child site is considered third party content. Internet Explorer, which uses the default privacy setting of Medium, silently rejects cookies sent from third party sites.
http://support.microsoft.com/kb/323752/en-us
I once heard someone say that an IFrame is actually a new instance of IE, but apparently it's a bit more complicated.
You might find this article by Milan Negovan helpful to explain why framed pages get a separate Session ID. The article also talks about the P3P solution mentioned by Gerrie Schenck above.
so the structure of your code/site would be something like:
Site A has Page 1 has an iframe which displays Site B
the iframe updates and now displays Page 2 from Site A
and when you right-click on the contents of the iframe you can verify that the url is corresponding to Site A?
If you debug, does Page 2 fire off your breakpoints as expected?