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.