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 on 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 could 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 so 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 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's logged in, they see their home page. That's a view, OK? 

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 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's us on the left, and our Model View Controller 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 going to make sure that everything's OK. It's going to 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'll transmit it that way, and then the view will 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, right? But you wouldn't see somebody else's. 

You'd be getting-- so you submit a query, you login to the model-- excuse me, you login 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 you the raw data for your news feed to the view, and then the view makes it 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's no direct connection between you and the model. There's always this buffer of the controller on the input side, and there's a buffer of the view on the output side. 

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 is-- 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 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 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 wouldn't even matter if you were logged in. No user can touch this dot 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? When 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 plus x that includes directory. Was 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 are these numbers actually translate to though? So these basically translate like this. If the permission is zero, nothing can happen. If it's one, you can execute the file-- if that's your permission. If it's two, you can write the file but you can't do anything else. If it's three, you can write and execute. And so on, as you can see. And 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 zeros and the green boxes as ones, these are actually just sets of binary numbers, right? 000 translates to decimal 0; 001, decimal 1; 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, so 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 plus 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 plus x-- is probably going to be exactly the same as chmod 711 file, because if you go back and look at the octal number scheme, ones and sevens 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 chmod-ing structure are. The green items here would be where all the green colored example was a second ago. The blue would be the 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 permission 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 dash l-- that's a lowercase l-- maybe I'll see something like this. It 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. And you can probably tell because it's got r's, w's, and x's 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 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 rm. You've seen the cryptic message "remove regular file"-- in this case, it'd 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 dash 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.