Looking at options for embedding the 3D Secure page inside my own order form, I came across the following:
"Some commerce sites will devote the full browser page to the authentication rather than using a frame (not necessarily an iFrame, which is a less secure object anyway)."
from http://en.wikipedia.org/wiki/3-D_Secure
Can someone give me the lowdown as to why iframes are less secure, and cause problems, as opposed to normal frames? And what are the basic differences?
The way I see it, iframe is the way to go.
The difference is an iframe is able to "float" within content in a page, that is you can create an html page and position an iframe within it. This allows you to have a page and place another document directly in it. A frameset allows you to split the screen into different pages (horizontally and vertically) and display different documents in each part.
Read IFrames security summary.
IFrame is just an "internal frame". The reason why it can be considered less secure (than not using any kind of frame at all) is because you can include content that does not originate from your domain.
All this means is that you should trust whatever you include in an iFrame or a regular frame.
Frames and IFrames are equally secure (and insecure if you include content from an untrusted source).
iframes are used a lot to include complete pages. When those pages are hosted on another domain you get problems with cross side scripting and stuff. There are ways to fix this.
Frames were used to divide your page into multiple parts (for example, a navigation menu on the left). Using them is no longer recommended.
Basically the difference between <frame> tag and <iframe> tag is :
When we use <frame> tag then the content of a web page constitutes of frames which is created by using <frame> and <frameset> tags only (and <body> tag is not used) as :
<html>
<head>
<title>HTML Frames</title>
</head>
<frameset rows="20%,70%,10%">
<frame name="top" src="/html/top.html" />
<frame name="main" src="/html/main.html" />
<frame name="bottom" src="/html/bottom.html" />
</frameset>
</html>
And when we use <iframe> then the content of web page don't contain frames and content of web page is created by using <body> tag (and <frame> and <frameset> tags are not used) as:
<html>
<head>
<title>HTML Iframes</title>
</head>
<body>
<p>See the video</p>
<iframe width="854" height="480" src="https://www.youtube.com/embed/2eabXBvw4oI"
frameborder="0" allowfullscreen>
</iframe>
</body>
</html>
So <iframe> just brings some other source's document to a web page. The <iframe> are used to specify inline frames or floating frames. The World Wide Web Consortium (W3C) included the <iframe> feature in HTML 4.01.
<frameset> tags were used to create frames with the tag <frame> whereas <iframe> fulfills functions of both <frame> and <frameset> tags. Unlike <frame> tags, <iframe> tags can also be placed inside the <body> tags.
Placement of <iframe> is easy, a coder can easily put the <iframe> tag among the other webpage tags, and also add several <iframe> tags if he/she wants. On the other hand, placing <frame> tags in <frameset> is bit complicated.
Note : <frame> tag and <frameset> tag are deprecated in HTML5
So now as use of <frame> and <frameset> tag is deprecated so web developers use <body> tag for creating content of a webpage and for embedding some other source's document in the web page <iframe> tags are used. But even <frame> tags were also used to embed other source's document in a webpage and even <iframe> tags are also used to create frames.
The only reasons I can think of are actually in the wiki article you referenced to mention a couple...
"The "Verified by Visa" system has drawn some criticism, since it is
hard for users to differentiate between the legitimate Verified by
Visa pop-up window or inline frame, and a fraudulent phishing site."
"as of 2008, most web browsers do not provide a simple way to check
the security certificate for the contents of an iframe"
If you read the Criticism section in the article it details all the potential security flaws.
Otherwise the only difference is the fact that an IFrame is an inline frame and a Frame is part of a Frameset. Which means more layout problems than anything else!
Inline frame is just one "box" and you can place it anywhere on your site.
Frames are a bunch of 'boxes' put together to make one site with many pages.
While the security is the same, it may be easier for fraudulent applications to dupe users using an iframe since they have more flexibility regarding where the frame is placed.
Related
I am doing some work that would require me building up html inside of embedded iframes. Sort of like jsbin does.
However I'm stumped with my very first spike.
How come my html isn't being rendered when I put it inside an iframe?
<!DOCTYPE html>
<html>
<head>
<meta charset=utf-8 />
<title>JS Bin</title>
</head>
<body>
<iframe>
<html>
<head><meta charset=utf-8 /></head>
<body>
<h1>Big Header</h1>
</body>
</html>
</iframe>
</body>
</html>
Here's my jsbin.
Additionally when I tried drawing some svgs inside the iframe with d3 they came out looking all weird and not scaling. After opening dev tools and editing the svg text as html I found that even adding a non-meaningful space anywhere would get it to redraw and render correctly. So bonus points if anyone can tell me any resources I can read up on cause clearly iframes don't work like I thought.
iframes need to be pointed at a page to load. you don't put html between iframe tags. if you put anything between iframe tags - it is text you want to display in the case the browser the client is using doesn't support the tag. you should make the html above its own local html page, and point the iframe src attribute above to point at that web page.
After a day of research:
Like Mike said, html inside an iframe is for the case the browser does not support iframes and will not show up otherwise. However, it IS absolutely possible to construct a document inside an iframe on the fly and without a server-side query. To do this, you have to use javascript to construct the document. You can get a reference to it and write html like so:
var iframe = document.getElementsByTagName('iframe')[0];
,doc = iframe.contentDocument || iframe.contentWindow.document
;
doc.open();
doc.write('<p>Some html</p>');
do.close();
Note that as Remy mentions here the document must be opened before writing and closed after.
From Richard Kiessig's ultra fast asp.net book,
Head section can't contain any tags that cause the browser to draw content on the screen, users will see noting until it has downloaded all resources in the section.
-- What he is referring from this statement?
<HEAD runat ="server">
<title>WebForm1</title>
<h1> Hi </h1>
</HEAD>
Browser is rending 'hi'.
h1 inside head is invalid html. It is not allowed. But if producers of webbrowsers would reject every invalid html-document, about 90% (or even more) websites would not displayed to the user.
So one browser producer built a browser who was able to render invalid sites too, and all the user started to use this browser. So the producers of correct webbrowsers had no other chance. They also built browsers that can render invalid html. And because of this, all webbrowsers that are in use are browsers that are able to render invalid html.
BUT:
There is no standard defined on how to render invalid html. So each producer has his own ideas about how to display an invalid document, and so, when you write invalid html, you could have luck, and the document looks fine in the one browser you used for developing and testing. But the users of your website do not only use YOUR browser. They use ALL available browsers, and if your html-code is invalid, the chances are really high, that many users use a browser you dont know, and this browser don't display what you want, but some garbage.
Conclusio:
Producers of really good Web-Browsers MUST produce browsers that can render any garbage.
Producers of really good html-documents MUST procuce valid html.
The statement “Head section can't contain any tags that cause the browser to draw content on the screen, users will see noting until it has downloaded all resources in the section.” is best ignored; it just causes confusion and lacks a point. Trying to correct the mistakes in it would take long and would not really lead to anything.
Regarding the treatment of the invalid markup
<HEAD runat ="server">
<title>WebForm1</title>
<h1> Hi </h1>
</HEAD>
the simple answer is that browsers have parsers that imply a closing </head> tag and an opening <body> tag, when they encounter <h1> while parsing a head element. This is in full conformance with HTML specifications.
In the fragment, the only invalid thing, apart from the runat ="server" attribute, which is not expected to be delivered to clients at all (it’s ASP not HTML), is the spurious end tag </HEAD>. The head element was already closed, it cannot be closed again.
Yeah, sure the <head></head> can contain all tags that by default carry the display:none; property. Those are elements like <meta> and <title>. But <h1> has to render on the screen, it is display:inline;. Most elements aren't display:none; though, and should be placed in the <body></body> section.
At that point it won't validate with w3c therefore you're breaking web standards. However, it should render just fine in all modern browsers. Most people would say you want to retain organization and quality when building web pages, part of that is making sure your code is the correct syntax.
ETA: Standard HTML5 markup...
<!DOCTYPE html>
<html>
<head>
<title>My Title</title>
<!--[if lt IE 9]>
<script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
</head>
<body>
<header>
</header>
<section>
</section>
<footer>
</footer>
</body>
</html>
In that lt IE9 comment, it adds HTML5 support to IE 8 and below which do not support it. ;-)
For school I have to make a website that must use frames. I complained to my teacher without success.
I want to use HTML5 but seems frames are deprecated. Am I required to use XHTML, HTML 4 or is there some work-around that makes my pages valid HTML5 with use of frames?
I know your class is over, but in professional coding, let this be a lesson:
"Deprecated" means "avoid use; it's going to be removed in the future"
Deprecated things still work - just don't expect support or future-proofing
If the requirement requires it, and you can't negotiate it away, just use the deprecated construct.
If you're really concerned, develop the alternative implementation on the side and keep it ready for the inevitable failure
Charge for the extra work now. By requesting a deprecated feature, they are asking you to double the work. You're going to see it again anyway, so might as well front-load it.
When the failure happens, let the interested party know that this was what you feared; that you prepared for it, but it'll take some time
Deploy your solution as quickly as you can (there will be bugs)
Gain rep for preventing excessive downtime.
Now, there are plenty of example of me answering questions with essays on why following validation rules are important. I've also said that sometimes you just have to be a rebel and break the rules, and document the reasons.
You can see in this example that framesets do work in HTML5 still. I had to download the code and add an HTML5 doctype at the top, however. But the frameset element was still recognized, and the desired result was achieved.
Therefore, knowing that using framesets is completely absurd, and knowing that you have to use this as dictated by your professor/teacher, you could just deal with the single validation error in the W3C validator and use both the HTML5 video element as well as the deprecated frameset element.
<!DOCTYPE html>
<html>
<head>
</head>
<!-- frameset is deprecated in html5, but it still works. -->
<frameset framespacing="0" rows="150,*" frameborder="0" noresize>
<frame name="top" src="http://www.npscripts.com/framer/demo-top.html" target="top">
<frame name="main" src="http://www.google.com" target="main">
</frameset>
</html>
Keep in mind that if it's a project for school, it's most likely not going to be something that will be around in a year or two once the browser vendors remove frameset support for HTML5 completely. Just know that you are right and just do what your teacher/professor asks just to get the grade :)
UPDATE:
The toplevel parent doc uses XHTML and the frame uses HTML5. The validator did not complain about the frameset being illegal, and it didn't complain about the video element.
index.php:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
<html>
<head>
</head>
<frameset framespacing="0" rows="150,*" frameborder="0" noresize>
<frame name="top" src="http://www.npscripts.com/framer/demo-top.html" target="top">
<frame name="main" src="video.html" target="main">
</frameset>
</html>
video.html:
<!doctype html>
<html>
<head>
</head>
<body>
<div id="player-container">
<div class="arrow"></div>
<div class="player">
<video id="vid1" width="480" height="267"
poster="http://cdn.kaltura.org/apis/html5lib/kplayer-examples/media/bbb480.jpg"
durationHint="33" controls>
<source src="http://cdn.kaltura.org/apis/html5lib/kplayer-examples/media/bbb_trailer_iphone.m4v" />
<source src="http://cdn.kaltura.org/apis/html5lib/kplayer-examples/media/bbb400p.ogv" />
</video>
</div>
</body>
</html>
Maybe some AJAX page content injection could be used as an alternative, though I still can't get around why your teacher would refuse to rid the website of frames.
Additionally, is there any specific reason you personally want to us HTML5?
But if not, I believe <iframe>s are still around.
You'll have to resort to XHTML or HTML 4.01 for this. Although iframe is still there in HTML5, its use is not recommended for embedding content meant for the user.
And be sure to tell your teacher that frames haven't been state-of-the-art since the late nineties. They have no place in any kind of education at all, except possibly for historical reasons.
Frames were not deprecated in HTML5, but were deprecated in XHTML 1.1 Strict and 2.0, but remained in XHTML Transitional and returned in HTML5. Also here is an interesting article on using CSS to mimic frames without frames. I just tested it in IE 8, FF 3, Opera 11, Safari 5, Chrome 8. I love frames, but they do have their problems, particularly with search engines, bookmarks and printing and with CSS you can create print or display only content. I'm hoping to upgrade Alex's XHTML/CSS frame without frames solution to HTML5/CSS3.
I am designing a web site that will rely on iFrames to show third party content. Given that, I have two problems.
This third party content may come in different encodings.
Almost nobody defines the encoding of a html file.
Ok, in this case the browser will try to infeer the encoding but as my tests shows it won´t infeer the encoding of each iframe sepparatly and, hence, some iframe will have it´s content messed up.
To reproduce create the following files:
index.html (encoded utf-8)
<html>
<iframe src="utf.html"> </iframe>
ááá
<br />
<iframe src="iso.html"> </iframe>
</html>
utf.html (encoded UTF-8)
<html>
ááááéééé
</html>
iso.html (encoded ISO-8859-1)
<html>
ááééíí
</html>
Right. If you see the results won´t be perfect.
If I add encoding info in meta tag properly it will work.
Remember I can´t change third party content. So, long story in short, the question is. In my example, is there a way to make it show all characters properly editing only index.html?
Thank you
There is not a way to do this client side. The browser will block this because of cross domain security policies. You will need to proxy the pages through your server and modify the output.
what is the internal mechanism of <bgsound> tag html?
I've looked into it:
For MIDI and WAV files, Internet Explorer loads winmm.dll and plays it through that. Specifically, it uses PlaySound. For MP3 files, it uses the ActiveMovie Control, runs it through the ActiveMovie Control Type Library (Quartz.dll, for info on its functions see here) to parse it, and plays that using DirectSound (DSOUND.DLL). Well, there you go.
The internal mechanism is entirely up to the browser vendor (should they choose to implement this non-standard element).
It is a black box, and shouldn't matter to anybody not developing the browser itself.
Not sure what you mean by internal mechanism, because bgsound is IE only and they keep there sources closed, but other vendors use embed instead of bgsound. What are you trying to do?
<html>
<head>
<title>Music</title>
<bgsound src="sound.mid" loop="infinite"> <!-- MS. Instead of infinite you can use a number. -->
</head>
<body>
<embed src="sound.mid" autostart="true" loop="true" hidden="true" height="0" width="0"> <!-- Others. -->
</body>
</html>