And this video, we're going to take a look at one technique we can use to solve both these problems
at the same time.
So both the fact that we might eventually end up with very large attributes on that source, doc, and
also the fact that we might eventually run into some trouble around parsing JavaScript code inside the
script.
So we're going to go over a very little side topic very quickly.
You might recall that.
Well, I'm sure you'll recall, because the last 12 videos or so that we've gone through have been all
about restricting communication between a child iFrame and the parent hosting document.
So we we went through all that trouble to make sure that we could restrict or turn off direct access
between the child and the parent.
In this video, we're going to take a look at one possible way that we can slightly bend those rules.
It turns out that we can still, even though we have turned off that direct access, we can still communicate
between these two different contexts in a very indirect way.
So let me show you an example of this inside my console.
I can make sure I've got top selected.
So I'm currently executing code inside of my top level context.
I'm going to write in here, window dot, add event listener, I'm going to listen for an event of type
message.
As a second argument, I'm going to put in and callback function, I'm going to receive some event and
then I'll cancel that event.
And then finally, as a third argument to add event listener, I'm going to put in simply false like
so.
So we are setting up a event listener on the window of our top level document right now.
This is the parent document.
It's going to run that I get back undefined, but the listener has been created.
Then after that, I'm going to write in a little bit of code into our text area and then submit it.
Remember, when we write in code inside of here and click submit, that code will be bundled, transpired
and then executed in the context of the iFrame.
So inside of here, I'm going to add in window or something, just parent, which you will recall is
a reference to the parent frame if we run that from inside of this iframe sorry.
Parent post message I'm going to post hello there.
And then as a second argument, I'm going to put in just a star by itself inside of a string.
Now, when we click on Submit, once again, we're going to transpire, bundle and then execute the
result inside the iFrame.
Let's try it out and see what happens.
All right, so we get a council log, this council log is coming from the event listener that we set
up inside of our parent frame.
So this is how we can do some very light communication between a child and a parent and in the opposite
direction as well.
We can post messages, as they are called, so we can post a message from a parent to a child or from
a child to a parent.
And this example, we have posted a message from our child up to the parent on either side.
We can set up event listeners to listen for these messages and then receive them and process them in
some way.
So once again, this is how we can still do some light communication between these different frames,
even after we have disabled direct access between the two.
This is thought of as still being secure in nature because it's a lot harder for some code running inside
the iFrame to try to reach out to the parent and try to access direct values such as set up event listeners.
Not technically possible, also cannot read values very easily, such as document cookie or try to get
access to local storage and stuff like that.
So this is thought of as again, being kind of a secure way of doing communication between these different
frames, even after we have disabled direct communication.
It might be kind of curious, one other thing, as long as we're talking about security, we've got
a star right here, that star is specifying the valid domains that can receive this message.
So right now, a star means any domain can receive this message and process this event.
But if I put in something like.
Google Dotcom, the hosting frame or this iFrame?
So in other words, the parent of this iFrame is localhost three thousand that does not match up with
Google dot com.
So if I submit this, we'll see that we get a nasty error message here because this message was interpreted
by a parent of Google dot com.
But right now the parent is at localist three thousand.
That's how you can get some further amount of security if you really care about it.
All right, last thing I want to do really quickly is take a look at the console log.
So this log is coming from our parent, it's coming from the event listener we set up right there inside
this event.
You'll notice that there is a data property and data contains the actual message that we posted from
inside of the iFrame.
So there's the yellow string.
All right, so this again, this is how we can do some very simple communication, so how does this
really help us?
Well, it's going to be pretty simple.
All we really have to do here is create the iFrame.
We're then going to listen for events coming from the parent.
We're going to watch for events saying that some new code has been created.
Whenever some new code has been bundled, we're going to receive it inside the iFrame and then just
go ahead and execute it.
And that's pretty much it.
So this is going to prevent this entire problem of having an attribute that is too long because we're
not going to communicate using attributes anymore.
We're going to instead communicate all this code as a plain string as intended.
Actually, that right there, we're also going to make sure or this is also going to help this entire
problem of having an escaped script tax, because now this code is going to be shared as a string as
opposed to a actual HTML snippet.
All right, so let's take a pause right here and start to implement this eventing stuff in the next
video.