All right, and the last video I know, I repeated myself several times, I apologize for that.
We eventually came to the conclusion that we don't really need a lot of this security stuff when running
locally.
But we decided, you know what, we're going to include it anyways because we might eventually expand
this application.
So one way that we can implement our app and still have this kind of security separation where content
is being served from different domains or in our case, different ports would be to do something like
this.
So we might have eventually our REACT application hosted at localhost four thousand five.
So whenever a user runs that command of JDBC serve or whatever else, they would open up their browser,
navigate to localist four thousand five and get our main react application.
That would be the main index, not HTML, along with the main JavaScript files to run the react up that
would load up the react up.
The user would see the notebook on the screen.
They would then start to change some code.
You and I would then bundle all the user's code inside the browser or something like that would then
reload the iFrame and when we reload the iFrame that is going to eventually display the user's code
or show the result of it actually execute the code.
We might decide to get the contents for the iFrame or something like from something like localhost four
thousand six.
And again, the entire point of having these different ports here is to make sure that the content inside
the iFrame cannot directly access the content inside of the parent frame or the parent document.
So this is something we could definitely implement, but just one thing I want to remind you about,
remember, we are bundling all of our users code inside the browser, so the browser itself is producing
the code that we are trying to execute.
So this diagram right here is not entirely accurate because there's not really going to be any step
where we somehow match our code from localhost four thousand six if we did eventually create a server
at that ports.
So you and I don't really have that step right there per say.
And that kind of just leaves us with creating this localhost four thousand six server just to serve
up this one single HTML document every single time that user makes a change to code.
So this is kind of a little bit of extra infrastructure that we are putting together just to satisfy
this one security requirement, just to say, hey, Browsr, look, we're getting an HTML document from
localhost four thousand six.
It is a different part.
Therefore, don't allow access to the parent document.
All I mean to say is this is going to be a lot of extra work just to satisfy this one security requirement.
Now, if we have to do extra work to satisfy security problems, well, that's OK, but I'm just kind
of curious.
Maybe there might be some other way that we could address this problem.
Maybe there is some other way that we can still have separation between the content inside of our iFrame
and the parent document without having to create this extra server.
That's what I'm kind of curious about, and that's what I kind of want to investigate just a little
bit.
If we could somehow remove that extra server, not only is that one less piece of infrastructure that
we have to put together inside of our project, but also potentially means that whenever a user changes
some code and we need to execute it, we might not need to make an extra request just to fetch in a
HTML document that is largely always going to be the same.
So removing that extra request and removing this extra piece of infrastructure, may that be pretty
nice.
So I'm kind of curious, is there any way that we can still have this separation between documents and
not have to create that extra server?
The answer is technically yes.
Remember this document or this diagram?
Remember, we had said that you only get direct access between frames when and this is what we have
really been focusing on in the last couple of videos.
We only get direct access between these things when an iFrame is loading up content from the same domain
port and protocol as the parent.
You and I have been obsessing over this case where we are loading up content from different ports so
that we do not get any direct access.
But remember, there was another entire condition on here.
If we have an iFrame element that does not have a sandbox property, whereas a sandbox of allow same
origin, then direct access is allowed.
That means that if we do not have that allows same origin property.
If we just put in sandbox equals empty string, there will be no direct access.
So in other words.
To allow some separation between the code that we are going to execute and the parent document, we
can either do this right here, we can create all that extra infrastructure or another way we could
address this without having to go through all this extra stuff is to just make a very small change.
This iFrame on the iFrame, we can add on a sandbox property of pretty much empty string and that is
going to isolate the contents of the iFrame.
We're going to get all the same kind of level of security without having to create all that extra infrastructure.
So kind of a happy middle ground.
So this is what we're going to try to do.
This is going to be our solution.
We're going to have localist four thousand five eventually.
Remember, right now, everything is technically running on localist 4000 or localhost 3000.
We're going to load everything up.
We're going to allow a user to change some code.
We're going to do all that bundling directly inside the browser.
We're then going to reload the iFrame and the iFrame is going to have that sandbox empty string attribute
assigned to it.
We're going to eventually put some value inside there, but right now it'll just be empty string.
We're then going to reload the iFrame, we're going to fetch some HTML document, load that up inside
the iFrame, we're going to somehow get our bundled JavaScript code inside there.
And because of our settings that we've applied to that iframe, the code that we are executing inside
there will not have access to the external document or that parent document, which is what we have
wanted all along to get that level of security.
So that's what we're going to do.
Now, having said that, I do want to say just throw one very quick note in here with a solution we
are putting in, there is going to be one or two little restrictions to the kind of code that users
are going to be able to write inside of our app.
This is an unfortunate downside to this approach.
There is a downside.
The downside is that the users who are using their application, they are not going to be able to use
local storage.
They're not going to be able to access cookies in a couple of other things in the code that they write.
So in other words, if we eventually implement all this stuff and a user puts in something inside,
if you of like local storage, not yet item of whatever, this code is unfortunately not going to work
as expected with a solution that we are coming up with here.
So it's kind of a tradeoff.
Our solution is can have way less infrastructure.
It's going to run extremely quickly.
It's going be very fast run users code because we don't have to match any extra HTML documents or anything
like that.
The one downside is we lose the ability to access some in browser features like local storage and one
or two or three other things.
So again, it is a tradeoff.
But at the end, the day I decided that this was kind of the most interesting solution, it really forces
us to understand more about Ephram's.
It limits the amount of infrastructure we are creating, which is always good.
So in my opinion, or this app, for the purposes of this course, decent, happy, medium, middle
ground.
All right, so enough discussion, let's start to do some implementation in the next video.