‫So how is all this different stuff relevant at all?
‫Well, here's what it really comes down to.
‫Remember, we were concerned about these three different items.
‫First, users code throwing errors, the fact that a user might mutate the dumb and finally, the fact
‫that there might be some kind of security issue if a user runs code provided by another user.
‫If we take the users code and we execute it in the context of an iFrame, it will completely solve all
‫three of these issues.
‫So the first two will be resolved if we just plain run the users code inside an iFrame, if we run their
‫code inside and iFrame and something crashes, no problem.
‫It is not being executed in the same context as our REACT application.
‫So really no big problem there whatsoever.
‫If the user decides to mutate the DOM in some fashion, they're going to mutate the DOM inside the iFrame,
‫not our parent document, so the user can mess around with the DOM as much as they please, and it's
‫not going to do anything bad to our application.
‫And then finally, if we can figure out a way to run the user's code inside of an iFrame with direct
‫communication disabled with a parent, we won't really have to worry about this scenario as well because
‫some malicious user will not be able to, say, set up a event listener on input elements and try to
‫harvest a user's password.
‫We can also figure out some way to disallow getting access to, say, the cookie, which might have
‫some authentication credentials inside of it as well.
‫You can actually we can go back over to code pen and code sandbox and see that they are implementing
‫an iFrame with all these same kind of scenarios or the same kind of consideration.
‫So back inside my browser between the last video and this one, I reopened code really quickly.
‫I'm going to take a look at that iframe once again and you'll notice.
‫That although they do have a sandbox property here with the allow same origin property, they are loading
‫up the content for the iFrame from a totally different domain.
‫They're loading up the content for the iFrame from code pen or CDP and IO.
‫So because they are loading up the content for this iFrame from a different domain than the parent document,
‫the parent document is being loaded from code and audio.
‫Direct communication is once again totally disallowed.
‫Same thing can be seen over on Code Sandbox.
‫Don't code sandbox at Code Sandbox dot.
‫Oh that means I fetch the parent frame from code sandbox dot io.
‫But if I look at the child frame.
‫And inspect it.
‫That has a SIRC right here of O.W. to seven kesby up to once again, different domain, different context,
‫no direct access or communication between the parent and the child is allowed.
‫This is pretty much what Code Sandbox is doing, what code man is doing, what Spittle is doing, what
‫all these different online coding tools are doing, they are all loading up your code inside of an iFrame.
‫Well, to be precise, they're actually loading up an HTML document inside an iFrame and then executing
‫your JavaScript code inside there.
‫And that's what is done to make sure that you don't accidentally mutate the DOM or have any malicious
‫code or anything like that.
‫All right, so now the last real consideration that we have here is, well, we understand how to create
‫an iFrame, we understand more or less how to show an HTML document.
‫How are we going to somehow get our JavaScript code inside there?
‫That's the last real thing that we need to figure out.
‫Let's take a pause right here and consider that in just a moment.