DOUG LLOYD: Sometimes when we're programming,
we do things so commonly, so frequently, and so many people
do the same idea or the same thing that it has a name.
MVC is exactly one such thing.
It's called a programming paradigm.
It's sort of like a best practices that have been distilled down
by people trying to do something, in this case implement a system of pages
that a user interacts with, a more complex website.
And it's done so commonly that it's recommended as a standard
that other people might like to follow.
And there's a very specific set of ways that one can follow this paradigm.
So MVC is a paradigm.
And the reason we use it is to abstract away details from the user.
Some things the user doesn't really need to see.
They just want to have a good user experience.
And we don't need to have them access every single file that
exists on our web server, perhaps.
There might be some files that are just used to bolster the user experience.
And so we can abstract those away.
We can sort of hide them, say the user can't work with them, but our pages--
our pages-- know how to deal with them and call them, or perhaps require
wants them or something like that.
The primary motivation for MVC is data security
because MVC usually comes up in the context of working with databases.
And in particular, we want to prevent users
from directly impacting databases.
We only want to do it indirectly, through our sort of filtration
or making sure that everything's OK by us
doing a little bit of error checking or safety
proofing before we send it to the database, where things could go wrong,
perhaps really wrong, if we're not careful.
So MVC stands for Model View Controller What do each of these mean?
Basically, model is your database.
It's where all the important data for your site
lives-- usernames, logins, passwords.
And you can update it, refer to it, pretty much everything like that.
You'd query a database.
You'd ask information from the database.
That's the model, all of the data where your site lives.
The view is kind of like the user experience.
It's the pages they see after they have requested information.
So maybe they submit their login information,
which they would do in a controller, which we'll talk about in a second.
They maybe submit their login information.
And the database is queried.
Information is requested and pulled from the database.
And then once the user has logged in, they see their home page.
That's a view.
And then the controller is what's called the business logic of your site.
And business logic is one of those terms that is sort of wishy-washy.
Like, what does business logic mean?
Basically, your business logic is your PHP.
Your user doesn't need to directly see your PHP.
But your PHP is probably what's going to be making requests to the database.
So the user will input information in a view, which
will sort of integrate a controller.
Like, they'll type into a form.
How that form processes information is the controller.
That's the PHP that's actually making the request to the model.
And then the model gives information to the view,
which gives it to the user, perhaps best visualized as follows.
So here we are here.
Here's us on the left, and our Model View Controller
sort of paradigm arrangement.
How does it work?
The user, us, makes a request to the controller.
We submit information such as by an HTTP form.
Based on that, the controller's job is to make sure
that what the user has given is not something that would damage the model.
And so the controller's gonna make sure that everything's OK.
It's gonna look very carefully.
If there's any errors, it'll stop things so the user can't get to the model.
But assuming everything's OK and it's a valid query,
the controller will query the model.
It'll ask it to provide information.
The model will provide that information to a page that's a view.
It will transmit it that way.
And then the view will sort of populate the information
requested from the model.
So, for example, if we're talking about logging into your Facebook page,
for example, the view would be the data that
came out of the model that refers to your friends and the news feed or stuff
like that.
But you wouldn't see somebody else's.
You'd be getting-- so you submit a query.
You log in to the page.
The controller uses your login information
to make a request to the model to make sure that you are who you say you are.
The model's like, OK, yes.
You are who you say you are.
So let me give you your news feed.
I'll give the raw data for your news feed to the view,
and then the view makes it sort of pretty, processes it in a way
that we're used to, displaying that information to the user.
Notice the connection that's not existing on this diagram.
There there's no direct connection between you and the model.
There's always this sort of buffer of the controller on the input side.
And there's a buffer of the view on the output side.
Now, maybe you're a good person, and so maybe you
wouldn't do any damage to the model.
But maybe you're not, or maybe there's somebody
who's a malicious user who would maybe want to damage your database,
maybe delete everything from your database, which
could be very expensive.
Obviously, having user data, there's value to having user data.
And so if we didn't put this buffer zone between the user
and the database, the user and the model,
things might not be going so well for us.
And so it's important to have this paradigm where the user can
interact with the database, sure.
But they have to go through us to do it.
And that's basically the idea with MVC.
It's trying to implement data security.
It's trying to protect the model from inadvertently or intentionally
malicious users.
So what happens when we apply this paradigm?
Well, we're separating the data required from our website, the model,
from the logic that implements our website's
functionality, the controller, and from the simple aesthetics and page
templates that comprise our user experience, the view.
What does this mean?
Well, it means you can make views visible to the user.
You can hide the model away.
And controllers the user can't maybe directly manipulate.
They don't need to access your PHP code.
They just need to see a form where they can type stuff in.
So then maybe the form is a view.
The controller is the PHP that the form submits to.
The controller makes a query to the model.
The model gives more information to a different view
that displays information to you.
Your programs can access all of your business logic.
But your users cannot directly access your business logic.
And one particularly, perhaps, visible illustration of this
is if you've ever received a 403 Forbidden error.
Have you ever gone to a web page and seen "403 Forbidden"?
It's sort of like 404 Not Found.
403 Forbidden means you tried to access a page that you don't have access to.
Perhaps that site is using MVC separation
to hide away its business logic that needs to exist on the server in order
for the page to work, but doesn't want you to directly access it.
So you might get a 403 Forbidden error.
And it won't even matter if you were logged in.
No user can touch this .php file.
They can only touch this one.
And this one, the one that they can touch,
perhaps can interact with the locked-down file
more indirectly than the user.
So we sometimes see this permissions error, this 403 Forbidden.
How do we change permissions so that things can or cannot be seen?
The way we do this typically is to use a Linux command called chmod, C-H-mod.
To do this, the format is pretty simple-- chmod permissions
and whatever file you want to apply that change to.
So maybe you'd see something like this-- chmod 600 helpers.php.
Or maybe you'd see this-- chmod a+x the includes directory.
What does this mean, though?
So there's two different ways that permissions are usually
applied using chmod.
The first is called the octal numbers method.
This usually applies permissions to three different categories
of users at the same time.
So chmod 711 file would allow you the right to read, write, and execute
your file, would allow others--
specifically, your group and the world-- to only execute the file.
That's what this translates to.
The first number there is what you can do.
The second number is what your group can do.
And the third is what the world can do, anybody who's visiting your page.
That's the world.
What do these numbers actually translate to, though?
So they basically translate like this.
If the permission is 0, nothing can happen.
If it's 1, you can execute the file if that's your permission.
If it's 2, you can write the file, but you can't do anything else.
If it's 3, you can write and execute, and so on, as you can see.
7 seven means you can do everything.
So why are these called octal numbers?
Well, if you think about it, here's, like, noes and yeses.
And if we think about them as red and green boxes,
maybe that makes it a little clearer.
But if we think about those red boxes as 0's and the green boxes
as 1's, these are actually just sets of binary numbers, right?
000 translates to decimal 0.
001, decimal one.
010 is decimal 2, and so on.
And so we call these octal numbers because there
are eight different possibilities.
There are eight different digits if we're
talking about three bits of information--
the read bit, the write bit, and the execute bit.
So now you can speak binary, decimal, hex, and octal.
So you know how to communicate with computers in four different number
systems.
That's pretty cool.
So besides the octal permission scheme, there's
also the symbolic permission scheme, which is slightly different
and usually is used best to apply or remove a permission across the board.
So chmod a+x file might add the right to execute to all three categories
of users--
yourself, your group, and the world.
That plus is the adding part.
The right to execute, that's the x.
And the fact that it applies to all three groups of users would be the a.
So this a+x is probably gonna be exactly the same as chmod 711 file
because if you go back and look at the octal number scheme,
1's and 7's give us the right to execute a file.
So this is probably the same.
And you can use this reference guide for what
the various things in the symbolic chmodding sort of structure are.
The green items here would be where all the green-colored example
was a second ago.
The blue would be blue.
The orange would be the orange.
So you can apply things to your group, to others, to the user,
or to everybody.
You can give them read, write, and execute access.
And you can add or remove or assign exactly a set
of permissions using this model.
How do we check what a file's permissions scheme is?
Before we change it, it's probably good to actually know
what the file permissions are.
One way to do this is to run ls, but just tweak it a little bit.
So if I type ls -l--
that's a lower case l--
maybe I'll see something like this, with looks a little bit cryptic.
But the part that we really care about is the stuff on the left over there.
That actually specifies a file permission scheme.
You can probably tell because it's got r's, w's, and x's sort of interspersed.
Those first three-- ignoring the first one
for a second, which we'll double back to.
Those first three after the first-- so the second, third,
and fourth characters of that 10-character string--
are the permissions that you have.
So apparently, I can read, write, and execute php.
I can read, write, and execute php-webdev.
And I can read and write test.php.
My group can do this.
So apparently with the php and php-webdev directories,
my group can write to them but nothing else.
And the world can't do anything.
So these files are not publicly accessible.
And if I tried to access them and I wasn't
running Apache to make them accessible, then I would get a 403 error.
It's a failure.
I tried to access a file, but I don't have permissions to do it.
And what is that first character?
Well, you can probably sort of extrapolate here
that the d's refer to directories and the dash refers
to so-called regular files.
And maybe you've seen this when you've tried to remove a file using our rm.
You've seen the sort of cryptic message "remove regular file"--
in this case it would be test.php.
Regular file is just something that's not a directory.
There are a couple of others here, but generally you're
going to see d's for directories and nothing for the first element.
But that's really all there is to it.
You can check file permissions using ls -l.
You can change them using chmod.
And, of course, use these changing the permissions
to enforce this MVC paradigm to protect the data on your website
and not allow users to access everything,
but only the stuff that they need to access in order for your page
to work the way you want it to work.
I'm Doug Lloyd.
This is CS50.