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?
Related
I have seen some answers about it but i have a same issue that is rather a little more complex.
I have a site about tourism build in wordpress localy and i have integrated in it some iframes from booking.com
The iframes are working good but when you click on the links inside it opens on a new window. All i want is to reload inside the iframe.
Also if some have worked with booking.com before i would like to ask...when you search from there search box and hit search is there a way not to open in a new window but instead in a new page inside the site?
In this case, due to cross-domain policy restrictions, you simply cannot control any of the booking.com iframe. That's by design, for security reasons. Unless you deal with a same-origin iframe (i.e. from the same domain name) there is nothing you can do here. You depend on booking.com's implementation entirely.
You may want to consider a plugin like http://wordpress.org/plugins/booking-search-hotel/ (found from a quick search) or see if other XML API solutions are available for more control.
I'm bulding an ASP.NET website just to test my skills, and I'm using lots of callbacks that doesn't require a page refresh, and the URL doesn't change. In this example, assume I'm bulding a web-based Outlook with a treeview, a grid, and a detail pane.
Is there a standard (published or assumed) that says I should postback, or even update my URL from time to time?
The Standard you are probably looking for is called usability. DHTML, Ajax, or whatever you want to call it is fine until it breaks the users expectation of browser behavior. When the back button fails to work, and users can't bookmark the page exactly as they expect, you're doing it wrong.
I don't know about an official standard, but you may want to check out Gmail to see a good example of how something similar was done. The URL changes on the site much more often than the page refreshes.
For a specialized purpose with Aweber regarding a newsletter subscription, I have a page loading a nested IFRAME inside, and both reside on the same domain. (Many other stackoverflow posts talk about different domains, but this question deals only with the same domain.) I need a cross-platform way (including browsers as old as the dawn of IE6) for the two to communicate.
For example, someone fills out name and email and clicks a checkbox, and the hidden IFRAME next to the checkbox sits in a setInterval() loop watching for that. When it receives notification, it grabs the name and email and does a form post.
I thought at first that I could just drop a cookie in the parent page, and then the IFRAME child could then sit in an interval watching for that cookie. But my tests show that this won't work. The cookie gets created -- but the IFRAME can't see it. So, I tried the meta-refresh technique in the IFRAME, and again it couldn't see that cookie for some reason.
The only solution I can come up with is that the parent page will take the checkbox click (we use jQuery) and do an AJAX data push to the server into a database. The IFRAME can then check on an interval back to the server via AJAX to see if the database value has changed, and react to it if so. But this seems like an over-engineered solution and I'm looking for an easier alternative that works cross-platform, even in earlier browsers from the timeframe of IE6 and forward.
It's much more simple: In the iframe, you can access the parent variable, which contains the parent window. So you can use parent.document to find the form, read the values, etc.
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.
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/>