DOUG LLOYD: Noen ganger når vi programmerer vi gjør ting så ofte, så ofte, og så mange mennesker gjøre det samme eller de samme idea-- ting, at den har et navn. MVC er akkurat en slik ting. Det kalles et programmeringsparadigme. Det er liksom som en beste praksis som er blitt destillert ned av folk prøver å gjøre noe. I dette tilfelle implementerer et system sider at en bruker samhandler med på en mer kompleks nettside. Og det er gjort så ofte som det er anbefalt som en standard at andre mennesker kanskje har lyst til å følge, og det er en veldig bestemt sett av måter at man kunne følge dette paradigmet. Så, er MVC et paradigme, og grunnen vi bruker det er å abstrakte bort detaljer fra brukeren. Noen ting brukerens ikke virkelig trenger å se. De vil bare ha en god brukeropplevelse, og vi trenger ikke å ha dem tilgang til hver enkelt fil som finnes på vår web server, kanskje. Det kan være noen filer som er like brukes til å styrke brukeropplevelsen, Og så kan vi abstrakte dem bort. Vi kan liksom skjule dem så brukeren kan ikke jobbe med dem, men vår pages-- vår pages-- vet hvordan man skal håndtere dem og ringe dem eller kanskje trenger, vil ha dem, eller noe sånt. 

Den primære motivasjonen for MVC er datasikkerhet, fordi MVC kommer vanligvis opp i sammenheng med å jobbe med databaser. Og spesielt vi ønsker å hindre brukere fra direkte påvirker databaser. Vi ønsker bare å gjøre det indirekte, gjennom vår filtrering. Eller å sørge for at alt er OK med oss gjøre en liten bit av feilsjekking eller sikkerhet korrektur før vi sende den til databasen, hvor ting kunne gå galt, kanskje virkelig galt, hvis vi ikke er forsiktig. 

Så MVC står for Model View Controller. Hva gjør hver av disse betyr? I utgangspunktet er modell databasen. Det er der alle viktige data for nettstedet lives-- brukernavn, innlogging, passord. Og du kan oppdatere den, se det, stort sett alt sånt. Du ville spørre en database, vil du spørre informasjon fra databasen. Det er model-- alle data hvor nettstedet ditt liv. 

Utsikten er typen som brukeropplevelsen. Det er de sidene de ser etter de har bedt om informasjon. Så kanskje de sender påloggings information-- som de ville gjøre i en kontroller, som vi skal snakke om i et sekund. De kanskje fremlegger påloggingsinformasjon, og databasen forespørres. Informasjon er forespurt og trekkes ut fra databasen. Og så når brukerens logget i, de ser deres hjemmeside. Det er et syn, OK? 

Og så kontrolleren er hva som er kalles forretningslogikk av nettstedet. Og forretningslogikk er en av de vilkår som er liksom wishy-washy-- liker, hva betyr forretningslogikk mener? I utgangspunktet din bedrift Logikken er din PHP. Din brukeren ikke trenger å direkte se din PHP, men PHP er trolig hva som skjer å være å gjøre forespørsler til databasen. 

Slik at brukeren vilje innspill informasjon i en visning, som vil integrere en kontroller. Liker, vil de skriver inn i en form. Slik som danner prosesser informasjon er kontrolleren. Det er PHP som faktisk er som reiser saken til den modellen. Og så den modellen gir informasjon til visningen, som gir den til brukeren, kanskje best visualisert som følger. 

Så her er vi. Her er oss på venstre side, og vår modell View Controller paradigme arrangement. Hvordan fungerer det? 

Den user-- us-- gjør en be til kontrolleren. Vi sender informasjon slik som ved en HTTP-form. Basert på det, er kontrolleren jobb er å sørge for at hva brukeren har gitt er ikke noe som ville skade modell. Og så kontrolleren kommer til å sørge for at alt er OK. Det kommer til å se veldig nøye. Hvis det er noen feil, vil det stoppe ting slik at brukeren ikke kan komme til modell. 

Men forutsatt at alt er OK, og det er en gyldig spørring, kontrolleren vil spørre model-- det vil be det å gi informasjon. Modellen vil gi det informasjon til en side som er en visning, det vil sende det som måte, og deretter visningen vil fylle ut informasjon spurt fra modellen. 

Så, for eksempel, hvis vi snakker om å logge inn på din Facebook-side, for eksempel. Utsikten ville være data som kom ut av den modellen som refererer til dine venner og nyheter mate eller sånne ting, ikke sant? Men du vil ikke se noen andres. 

Du vil bli getting-- så du sender en spørring, du logge inn på model-- unnskyldning meg, logg deg til siden. Kontrolleren bruker påloggingsinformasjonen for å gjøre en forespørsel til modellen for å gjøre sikker på at du er den du sier du er. Modellen er som, OK, ja, du er den du sier du er, så la meg gi deg din nyhetsstrøm. Jeg skal gi deg rådata for din nyhetsfeed til visningen, og deretter visningen gjør det pen, behandler det på en måte som vi er vant til, viser som informasjon til brukeren. 

Legg merke til den tilkoblingen som er ikke eksisterende på dette diagrammet. Det er ingen direkte sammenheng mellom deg og modellen. Det er alltid denne bufferen av kontrolleren på inngangssiden, og det er en buffer av se på utgangssiden. 

Kanskje er du en god person, og så kanskje du ville ikke gjøre noen skade på modellen, men kanskje du ikke. Eller kanskje det er noen som har en ondsinnet bruker som ville kanskje ønsker å skade databasen, kanskje slette alt fra databasen, noe som kan være svært kostbart. Selvfølgelig, har brukerdata er-- det er verdi å ha brukerdata. Og så hvis vi ikke sette denne bufferen sonen mellom brukeren og database-- brukeren og model-- ting kanskje ikke går så bra for oss. 

Og så det er viktig å har dette paradigmet hvor brukeren kan samhandle med databasen, sikker, men de må gå gjennom oss å gjøre det. Og det er i utgangspunktet ideen med MVC. Det prøver å implementere datasikkerhet. Den prøver å beskytte modellen utilsiktet eller med vilje ondsinnede brukere. 

Så hva skjer når vi bruke dette paradigmet? Vel, vi skille data kreves fra vår website-- den model-- fra logikken som implementerer vår nett functionality-- den controller-- og fra de enkle estetikk og side maler som utgjør vår bruker erfaring-- utsikten. Hva betyr dette? Vel, betyr det at du kan gjøre ser synlig for brukeren. Du kan skjule modellen unna. Og controllers-- brukeren kan ikke kanskje direkte manipulere. De trenger ikke å få tilgang til PHP-kode. De trenger bare å se et skjema der de kan skrive ting i. Så kanskje formen er en visning, kontrolleren er PHP at skjemaet sender til, kontrolleren gjør en forespørsel til modellen, modellen gir mer informasjon til et annet syn som viser informasjon til deg. 

Dine programmer kan få tilgang alle dine forretningslogikk, men brukerne kan ikke direkte tilgang til forretningslogikk. Og en særlig kanskje synlig illustrasjon av dette er du noen gang har mottatt en 403 Forbidden error. Har du noen gang gått til en web siden og sett 403 Forbidden? Det er liksom som 404 Not Found. 

403 Forbidden betyr at du prøvde å få tilgang en side som du ikke har tilgang til. Kanskje dette nettstedet er bruker MVC separasjon å gjemme bort sin forretningslogikk som må eksistere på serveren i rekkefølge for siden å jobbe, men ikke Vil du direkte tilgang til den. Så du kan få en 403 Forbidden error. 

Og det ville ikke engang saken hvis du var logget inn. Ingen bruker kan røre denne dot PHP-filen. De kan bare berøre denne, og denne one-- den ene at de kan touch-- kanskje kan samhandle med nedlåst fil mer indirekte enn brukeren. 

Så, vi noen ganger se denne tillatelser feil, dette 403 Forbidden. Hvordan kan vi endre tillatelser så at ting kan eller ikke kan bli sett? Når vi gjør dette vanligvis er å bruke en Linux-kommando som heter chmod-- C-H-mod. 

For å gjøre dette, er ganske formatet simple-- chmod, tillatelser, og hva filen du vil til å anvende denne endringen til. Så, kanskje du ville se noe som dette-- chmod 600 helpers.php. Eller kanskje du vil se dette-- chmod et pluss x som inkluderer katalogen. Var betyr dette selv? Så, det er to forskjellige måter at tilgangen er vanligvis påføres med chmod. Den første kalles oktale tall metoden. Dette gjelder vanligvis tillatelser til tre forskjellige kategorier av brukere på samme tid. Ville så chmod 711 fil tillate deg rett til å lese, skrive, og utføre filen, ville tillate others-- spesifikt gruppen og world-- å bare kjøre filen. Det er hva dette betyr. Det første tallet er det er hva du kan gjøre, det andre tallet er hva gruppen kan gjøre, og den tredje er det verden kan gjøre. Alle som er på besøk din side, er at verden. 

Hva er disse tallene faktisk oversette til selv? Så disse i utgangspunktet sette som dette. Dersom tillatelsen er null, ingenting kan skje. Hvis det er en, kan du utføre file-- hvis det er din tillatelse. Hvis det er to, kan du skrive til fila men du kan ikke gjøre noe annet. Hvis det er tre, du kan skrive og utføre. Og så videre, som du kan se. Og sju betyr at du kan gjøre alt. 

Så hvorfor er disse kalles oktale tall? Vel, hvis du tenker på det, her er som noes og yeses, og hvis vi tenker på dem som røde og grønne bokser, kanskje det gjør det litt klarere. Men hvis vi tenker på de røde boksene som nuller og de grønne boksene som de, disse er faktisk bare sett av binære tall, ikke sant? 000 oversettes til desimal 0; 001, desimal 1; 010 er desimal to, og så videre. Og så kaller vi disse oktal tall fordi det er åtte forskjellige muligheter. Det er åtte forskjellige tall hvis vi er snakker om tre- biter av information-- lese litt, skrive bit, og kjøre litt. Så nå kan du snakke binære, desimal, hex og oktale. Så du vet hvordan du skal kommunisere med datamaskiner i fire forskjellige tall systemer, så det er ganske kult. 

Derfor, i tillegg til oktal tillatelse ordningen, det er også den symbolske tillatelse Ordningen, som er litt annerledes og vanligvis brukes best å bruke eller fjerne en tillatelse over hele linja. Så chmod et pluss x fil kan legge til rette å utføre alle tre kategorier av users-- selv, din gruppe, og verden. At pluss er å legge en del. Retten til å kjøre, det er x. Og det faktum at det gjelder alle tre grupper av brukere ville være en. 

Så dette-- et pluss X- er trolig kommer å være nøyaktig den samme som chmod 711 fil, fordi hvis du går tilbake og se på oktaltallet ordningen, enere og syvere gi oss rett til å utføre en fil. Så dette er trolig den samme. 

Og du kan bruke denne referansehåndbok for hva de ulike ting i symbolsk chmod-ing strukturen er. De grønne elementer her vil være hvor all grønn eksempel var en andre siden. Den blå ville være blå. Den oransje ville være oransje. Så du kan bruke ting til gruppe, til andre, til brukeren, eller til alle. Du kan gi dem lese, skrive, og utføre tilgang, og du kan legge til eller fjerne eller tildele nøyaktig et sett av tillatelser ved bruk av denne modellen. 

Hvordan sjekker vi hva en filen tillatelse ordningen er? Før vi endre det, er det sannsynligvis bra å faktisk vite hva filrettigheter er. En måte å gjøre dette på er å kjøre ls men bare finpusse det litt. Så hvis jeg skriver ls dash l-- det er en liten bokstav l-- kanskje Jeg vil se noe sånt som dette. Det ser litt kryptisk, men den delen som vi virkelig bryr seg om er ting på venstre der borte. Som faktisk spesifiserer en fil tillatelse ordningen. Og du kan sikkert fortelle fordi det er fikk r-tallet, w-tallet, og x er ispedd. 

De første three-- ignorerer den første for en andre, noe som vi vil doble tilbake til. De første tre etter den first-- så den andre, tredje og fjerde tegn av det 10. tegnstreng er de tillatelser som du har. Så tilsynelatende jeg kan lese, skrive, og utføre PHP. Jeg kan lese, skrive og utføre PHP WebDev, og jeg kan lese og skrive test.php. 

Min gruppe kan gjøre dette. Så tilsynelatende med PHP og PHP WebDev kataloger, min gruppe kan skrive til dem, men ingenting annet. Og verden kan ikke gjøre noe. Så disse filene er ikke offentlig tilgjengelig og hvis jeg prøvde å tilgang til dem, og jeg var ikke kjører Apache å gjøre dem tilgjengelige, Da ville jeg få en 403-feil. Det er en fiasko. Jeg prøvde å få tilgang til en fil, men jeg har ikke tillatelse til å gjøre det. Og hva er det første tegnet? Vel, du kan sikkert ekstrapolere her at d's refererer til kataloger og dashbordet viser til såkalte "vanlige filer." Og kanskje du har sett denne når du har prøvde å fjerne en fil med rm. Du har sett den kryptiske meldingen "fjern vanlig fil" - i dette tilfellet, det ville være test.php. Vanlig fil er bare noe det er ikke en katalog. Det er et par andre her, men generelt du er kommer til å se d's for kataloger og ingenting for det første element. Men det er egentlig alt som skal til. Du kan sjekke fil tillatelser som bruker ls dash l, du kan endre dem ved hjelp av chmod. Og, selvfølgelig, bruker these-- endre tillatelser å håndheve denne MVC paradigmet til beskytte dataene på nettstedet ditt og ikke tillate brukere for å få tilgang til alt, men bare ting som de trenger å få tilgang til for at siden din til å fungere slik du vil ha det til å fungere. 

Jeg er Doug Lloyd. Dette er CS50.