Sima kijelentkezés html nézet. A bejelentkezési és kijelentkezési nézetek. Hozzon létre egy kezdőlapot

Sokan úgy kezdenek írni egy projektet, hogy egyetlen feladattal működjön, anélkül, hogy azt sugallnák, hogy többfelhasználós irányítási rendszerré nőhet, nos, mondjuk, tartalom vagy, Isten ne adjon, produkció. Úgy tűnik, hogy minden klassz és hűvös, minden addig működik, amíg meg nem kezded megérteni, hogy az írott kód teljes egészében mankókból és kemény kódokból áll. Kód elrendezéssel, kérésekkel és mankókkal vegyítve, néha olvashatatlan is. Sürgős probléma merül fel: új funkciók hozzáadásakor nagyon sokáig kell bütykölnie ezzel a kóddal, és emlékeznie kell arra, hogy "mi volt ott írva?" és átkozd magad a múltban.

Lehet, hogy hallott már a tervezési mintákról, sőt lapozgatta ezeket a kiváló könyveket:

E. Gamma, R. Helm, R. Johnson, J. Vlissides "Objektumorientált tervezési technikák. Tervezési minták ";
M. Fowler "Vállalati szoftveralkalmazások architektúrája".

És sokan, nem félve a hatalmas kézikönyvektől és dokumentációktól, megpróbálták tanulmányozni a modern keretrendszereket, és szembesültek a megértési nehézségekkel (sok egymással ügyesen összekapcsolt építészeti koncepció jelenléte miatt) a modern eszközök tanulmányozására és alkalmazására a hátsó égő.

A bemutatott cikk elsősorban a kezdők számára lesz hasznos. Mindenesetre remélem, hogy pár óra múlva képet kaphat az MVC mintázatának megvalósításáról, amely az összes modern webes keret alapja, valamint "ételt" kap a további gondolkodásra " hogyan kell csinálni." A cikk végén hasznos linkek találhatók, amelyek segítenek megérteni, hogy az MVC mellett milyen webkeretek készülnek és hogyan működnek.

A kemény alapú PHP-programozók valószínűleg nem találnak valami újat maguknak ebben a cikkben, de a fő szöveggel kapcsolatos megjegyzéseik és megjegyzéseik nagyon hasznosak lennének! Mivel elmélet nélkül a gyakorlat lehetetlen, és gyakorlat nélkül az elmélet haszontalan, akkor előbb lesz egy kis elmélet, majd továbbállunk a gyakorlatra. Ha már ismeri az MVC fogalmát, kihagyhatja az elméleti részt és rögtön a gyakorlatba ugorhat.

1. Elmélet

Az MVC minta az alkalmazás struktúrájának egyszerű felépítését írja le, azzal a céllal, hogy elkülönítse az üzleti logikát a felhasználói felülettől. Ennek eredményeként az alkalmazás könnyebben méretezhető, tesztelhető, karbantartható és természetesen megvalósítható.

Tekintsük az MVC minta fogalmi sémáját (véleményem szerint ez a legsikeresebb séma, amit láttam):

Az MVC architektúrában a modell adatot és üzleti logikai szabályokat biztosít, a nézet felelős a felhasználói felületért, a vezérlő pedig a modell és a nézet kölcsönhatásáért.

Az MVC-alkalmazások tipikus munkafolyamata a következőképpen írható le:

Amikor a felhasználó belép egy webes erőforrásba, az inicializáló szkript létrehozza az alkalmazás egy példányát, és elindítja végrehajtásra.
Ez megjeleníti például a webhely kezdőlapjának nézetét.
Az alkalmazás megkapja a kérést a felhasználótól, és meghatározza a kért vezérlőt és műveletet. Mesteroldal esetén az alapértelmezett művelet ( index).
Az alkalmazás példányosítja a vezérlőt és futtatja a műveleti módszert,
amely például modellhívásokat tartalmaz, amelyek információkat olvasnak le az adatbázisból.
Ezt követően a művelet nézetet generál a modelltől kapott adatokkal, és megjeleníti az eredményt a felhasználó számára.

Modell- tartalmazza az alkalmazás üzleti logikáját, és tartalmazza a beolvasás (ezek lehetnek ORM módszerek), a feldolgozás (például érvényesítési szabályok) és a specifikus adatok megadásának módszereit, ami gyakran nagyon vastagsá teszi őket, ami teljesen normális.
A modell nem léphet közvetlenül kapcsolatba a felhasználóval. A felhasználói kéréssel kapcsolatos összes változót a vezérlőben kell feldolgozni.
A modell nem hozhat létre HTML-t vagy más megjelenítő kódot, amely a felhasználó igényeitől függően változhat. Az ilyen kódot nézetekben kell feldolgozni.
Ugyanaz a modell például: a felhasználói hitelesítési modell mind a felhasználó, mind az alkalmazás adminisztratív részében használható. Ebben az esetben áthelyezheti a közös kódot egy külön osztályba, és örökölheti belőle, meghatározva az alalkalmazás-specifikus módszereket az örököltekben.

Kilátás- a vezérlőtől és a modelltől kapott adatok külső megjelenítésének beállítására szolgál.
A nézetek HTML jelölést és a PHP kód kis beillesztését tartalmazzák az adatok bejárásához, formázásához és megjelenítéséhez.
Nem szabad közvetlenül elérnie az adatbázist. Ezt modelleknek kell elvégezni.
Nem kell működnie a felhasználói kérésből nyert adatokkal. Ezt a feladatot a vezérlőnek kell elvégeznie.
Közvetlenül hozzáférhet a vezérlő vagy a modellek tulajdonságaihoz és módszereihez, hogy készen álljon a kimenetre.
A nézetek általában egy közös sablonra oszlanak, amely tartalmazza az összes oldal közös jelölését (például egy fejlécet és láblécet), valamint a sablon olyan részeit, amelyek a modell adatainak megjelenítésére vagy az adatbeviteli űrlapok megjelenítésére szolgálnak.

Vezérlő- a ragasztó, amely a modelleket, nézeteket és más alkatrészeket összekapcsolja egy gyártási alkalmazással. Az adatkezelő felelős a felhasználói kérések kezeléséért. A vezérlő nem tartalmazhat SQL lekérdezéseket. Legjobb modellekben tarthatók. A vezérlő nem tartalmazhat HTML-t vagy más jelölést. A fajnál ki kell venni.
Egy jól megtervezett MVC alkalmazásban a vezérlők általában nagyon vékonyak, és csak néhány tucatnyi kódot tartalmaznak. Amit nem lehet elmondani a CMS Joomla hülye zsírszabályozóiról (SFC). A vezérlő logika meglehetősen tipikus, és nagy részét alaposztályokban hajtják végre.
A modellek viszont nagyon vastagok és tartalmazzák az adatfeldolgozó kód nagy részét. az abban foglalt adatstruktúra és üzleti logika általában meglehetősen alkalmazás-specifikus.

1.1. Első vezérlő és Oldalvezérlő

A legtöbb esetben a felhasználó interakciója a webalkalmazással a linkekre kattintással történik. Most nézze meg a böngésző címsorát - erre a linkre kapta ezt a szöveget. Más linkek, például az oldal jobb oldalán található linkek, más tartalmat adnak Önnek. Így a link egy speciális parancsot jelent a webalkalmazáshoz.

Remélem, már észrevette, hogy a különböző webhelyek tökéletesen eltérő formátumúak lehetnek a címsáv felépítéséhez. Minden formátum képviselheti egy webalkalmazás architektúráját. Bár ez nem mindig így van, a legtöbb esetben egyértelmű tény.

Fontolja meg a címsáv két lehetőségét, amelyek valamilyen szöveget és felhasználói profilt mutatnak.

Első lehetőség:

www.example.com/article.php?id=3
www.example.com/user.php?id=4

Itt minden szkript felelős egy adott parancs végrehajtásáért.

Második lehetőség:

www.example.com/index.php?article=3
www.example.com/index.php?user=4

És itt az összes hívás egy forgatókönyv szerint zajlik. index.php.

A multi-touch megközelítés a phpBB fórumokon látható. A fórum szkripten keresztül tekinthető meg viewforum.php, végignézve a témát viewtopic.php stb. A második megközelítés, egyetlen fizikai szkriptfájlon keresztüli hozzáféréssel, megfigyelhető a kedvenc CMS MODX-en, ahol az összes hívás megy keresztül index.php.

Ez a két megközelítés teljesen különbözik egymástól. Az első a Page Controller mintára jellemző, a második megközelítést pedig az Front Controller minta hajtja végre. Az oldalvezérlő meglehetősen egyszerű logikájú webhelyekhez jó. Viszont a kérésvezérlő összesíti a kérések feldolgozásához szükséges összes műveletet egy helyre, ami további képességeket biztosít számára, aminek köszönhetően nehezebb feladatokat lehet végrehajtani, mint általában az oldalvezérlő kezeli. Nem térek ki az oldalvezérlő megvalósításának részleteire, de csak annyit mondok, hogy a gyakorlati részben a kérésvezérlőt fejlesztik ki (némi látszat).

1.2. URL-útválasztás

Az URL-útválasztás lehetővé teszi az alkalmazás konfigurálását olyan kérések fogadására, amelyek olyan URL-ekből származnak, amelyek nem egyeznek az alkalmazás tényleges fájljaival, valamint olyan CNC-ket használhat, amelyek szemantikailag értelmesek a felhasználók számára, és előnyben részesítik a keresőmotorok optimalizálását.

Például egy normál, kapcsolatfelvételi űrlapot megjelenítő oldal esetében az URL így nézhet ki:
http://www.example.com/contacts.php?action=feedback

Hozzávetőleges feldolgozási kód ebben az esetben:
kapcsoló ($ _GET ["action"]) (eset "about": need_once ("about.php"); // "Rólunk" oldal szünet; case "kapcsolatok": need_once ("contacts.php"); // "Kapcsolatok" oldal szünet; case "visszacsatolás": required_once ("feedback.php"); // "Visszajelzés" oldal szünet; alapértelmezett: required_once ("page404.php"); // "404" oldal törés; )
Azt hiszem, szinte mindenki megtette ezt korábban.

Az URL-útválasztó motor segítségével konfigurálhatja alkalmazását úgy, hogy fogadja el ezeket a kéréseket ugyanazon információk megjelenítésére:
http://www.example.com/contacts/feedback

Itt a kapcsolatok egy vezérlő, a visszacsatolás pedig egy kapcsolattartónak nevezett vezérlő módszer, amely visszajelzési űrlapot jelenít meg stb. A gyakorlati részben még visszatérünk erre a kérdésre.

Érdemes tudni azt is, hogy számos webkeret útválasztója lehetővé teszi tetszőleges URL-útvonalak létrehozását (adja meg, hogy mit jelentenek az URL egyes részei), valamint szabályokat azok feldolgozásához.
Most elegendő elméleti ismerettel rendelkezünk ahhoz, hogy továbblépjünk a gyakorlatra.

2. Gyakorlat

Először hozzuk létre a következő fájl- és mappaszerkezetet:

Előretekintve azt mondom, hogy az alapmappában tárolódnak az alap Model, View és Controller osztályok.
Leszármazottaikat a vezérlők, a modellek és a nézetek könyvtárai tárolják. File index.php ez egy pont az alkalmazás fordulóján. File bootstrap.php kezdeményezi az alkalmazás letöltését, összekapcsolja az összes szükséges modult stb.

Következetesen fogunk menni; nyissa meg az index.php fájlt, és töltse ki a következő kóddal:
ini_set ("display_errors", 1); demand_once "application / bootstrap.php";
Nem lehet kérdés.

Ezután menjünk egyenesen a fájlhoz bootstrap.php:
need_once "core / model.php"; need_once "core / view.php"; need_once "core / controller.php"; need_once "core / route.php"; Útvonal :: start (); // indítsa el az útválasztót
Az első három sor nem létező törzsfájlokat tartalmaz. Az utolsó sorok összekapcsolják a fájlt az útválasztó osztállyal, és a statikus indítási módszer meghívásával elindítják végrehajtásra.

2.1. URL-útválasztó megvalósítása

Most térjünk el az MVC minta megvalósításától és foglalkozzunk az útválasztással. Az első lépés, amelyet be kell írnunk, a következő kód beírása .htaccess:
RewriteEngine On RewriteCond% (REQUEST_FILENAME)! -F RewriteCond% (REQUEST_FILENAME)! -D RewriteRule. * Index.php [L]
Ez a kód átirányítja az összes oldal feldolgozását ide: index.php, amire szükségünk van. Emlékszel az első részben az elülső vezérlőről?

Az útválasztást külön fájlba tesszük route.php a törzskönyvtárhoz. Ebben a fájlban leírjuk a Route osztályt, amely a vezérlő metódusait futtatja, amelyek viszont az oldal nézetet generálják.

Route.php fájl tartalma

osztály Útvonal ( statikus függvény indítása () ( // vezérlő és alapértelmezett művelet$ controller_name = "Fő"; $ action_name = "index"; $ route = explode ("/", $ _SERVER ["REQUEST_URI"]); // megkapja a vezérlő nevét if (! üres ($ útvonal)) ($ vezérlőnév = $ útvonal;) // megkapja a művelet nevét if (! üres ($ útvonal)) ($ action_name = $ útvonal;) // előtagok hozzáadása$ model_name = "Model_". $ controller_name; $ controller_name = "Controller_". $ controller_name; $ action_name = "action_". $ action_name; // csatlakoztassa a fájlt a modellosztályhoz (lehet, hogy a modellfájl nem létezik)$ model_file = strtolower ($ model_name). ". php"; $ model_path = "alkalmazás / modellek /". $ model_file; if (file_exists ($ model_path)) (tartalmazza az "application / models /" szót. $ model_file;) // csatlakoztassa a fájlt a vezérlő osztályhoz$ controller_file = strtolower ($ controller_name). ". php"; $ controller_path = "alkalmazás / vezérlők /". $ controller_file; if (file_exists ($ controller_path)) (tartalmazza az "application / controllers /". $ controller_file;) else ( / * helyes lenne kivételt vetni ide, de az egyszerűség kedvéért azonnal átirányítunk egy 404-es oldalra * /Útvonal :: ErrorPage404 (); ) // vezérlő létrehozása$ controller = új $ controller_name; $ action = $ action_name; if (metódus_ létezik ($ vezérlő, $ művelet)) { // a vezérlő műveletének meghívása$ vezérlő -> $ művelet (); ) más ( // bölcsebb lenne itt is kivételt dobniÚtvonal :: ErrorPage404 (); )) függvény ErrorPage404 () ($ host = "http: //". $ _ SERVER ["HTTP_HOST"]. "/"; fejléc ("HTTP / 1.1 404 nem található"); fejléc ("Állapot: 404 nem található"); fejléc ("Location:". $ host. "404"); ))

Ne feledje, hogy az osztály nagyon egyszerűsített logikát hajt végre (a terjedelmes kód ellenére), és akár biztonsági problémái is lehetnek. Ezt szándékosan tették, mivel teljes értékű útválasztási osztály megírása legalább külön cikket érdemel. Vegyük fontolóra a főbb pontokat ...

A $ _SERVER ["REQUEST_URI"] globális tömb eleme tartalmazza a teljes címet, amelyhez a felhasználó felvette a kapcsolatot.
Például: example.ru/contacts/feedback

A funkció használata felrobban a cím komponensekre van osztva. Ennek eredményeként megkapjuk a vezérlő nevét, az adott példához ez a vezérlő kapcsolatokés a mi esetünkben az akció neve - Visszacsatolás.

Ezután a modellfájl csatlakoztatva van (lehet, hogy nincs jelen a modell), és ha van ilyen, akkor a vezérlőfájl, és végül a vezérlő példányos lesz, és a művelet meghívásra kerül, még egyszer, ha a vezérlőosztályban leírták.

Így például amikor a címre megy:
example.com/portfolio
vagy
example.com/portfolio/index
az útválasztó a következőket fogja tenni:

tartalmazza a model_portfolio.php fájlt a Model_Portfolio osztályt tartalmazó modell mappából;
tartalmazza a controller_portfolio.php fájlt a Controller_Portfolio osztályt tartalmazó vezérlők mappájából;
létrehoz egy példányt a Controller_Portfolio osztályból, és meghívja az abban leírt alapértelmezett műveletet - action_index.

Például, ha a felhasználó megpróbál kapcsolatba lépni egy nem létező vezérlő címével:
example.com/ufo
akkor átirányítja a "404" oldalra:
pelda.com/404
Ugyanez történik, ha a felhasználó olyan műveletet hív meg, amelyet a vezérlő nem ír le.

2.2. Vissza az MVC megvalósításhoz

Menjünk a törzsmappába, és adjunk hozzá még három fájlt az route.php fájlhoz: model.php, view.php és controller.php

Hadd emlékeztessem önöket arra, hogy tartalmazni fognak alaposztályokat, amelyeket most elkezdünk írni.

A fájl tartalma model.php
osztály Modell ( nyilvános függvény get_data () { } }
A modellosztály egyetlen üres adatletöltési módszert tartalmaz, amely átfedésben lesz a leszármazott osztályokban. Amikor leszármazott osztályokat hozunk létre, minden világosabbá válik.

A fájl tartalma view.php
osztály nézet ( // public $ template_view; // itt megadhatja az alapértelmezett általános nézetet. függvény generálása ( $ content_view, $ template_view, $ data = null) { / * if (is_array ($ data)) (// átalakítja a tömb elemeit változókkivonatkivonattá ($ data);) * / tartalmazza az "application / views /" alkalmazást. $ template_view; ))
Nem nehéz kitalálni, hogy a módszer generál kilátás kialakítására tervezték. A következő paramétereket adjuk át neki:

$ content_file - az oldal tartalmát megjelenítő nézetek;
$ template_file - az összes oldalra sablon;
A $ data egy tömb, amely oldal tartalmi elemeket tartalmaz. Általában kitölti a modellt.

Az include funkció dinamikusan összeköti az általános sablont (nézetet), amelybe a nézet beágyazódik
egy adott oldal tartalmának megjelenítéséhez.

Esetünkben az általános sablon fejlécet, menüt, oldalsávot és láblécet tartalmaz, az oldalak tartalma pedig külön formában lesz. Ez megint az egyszerűség kedvéért történik.

A fájl tartalma controller.php
osztály Vezérlő ( nyilvános $ modell; nyilvános $ nézet; function __construct () {$ this -> nézet = új nézet (); )))
Módszer action_index- ez az alapértelmezett művelet, felülírjuk a leszármazott osztályok megvalósításakor.

2.3. A Model and Controller leszármazott osztályok megvalósítása, View létrehozása

Most kezdődik a móka! Névjegykártya-oldalunk a következő oldalakból áll:

a fő
Szolgáltatások
Portfólió
Névjegyek
És még - "404." oldal

Minden oldalnak megvan a saját vezérlője a vezérlők mappájából és nézetek a nézetek mappából. Egyes oldalak használhatják a modellt vagy a modellek mappából származó modelleket.

Az előző ábrán a fájlt külön kiemelik template_view.php Az összes oldalon közös egy sablont tartalmazó jelölés. A legegyszerűbb esetben így nézhet ki:
<html lang = "ru"> <fej> <meta karakterkészlet = "utf- 8"> <cím> a főcím> fej> <test> $ content_view; ?> test> html>
Annak érdekében, hogy a webhely megjeleníthető legyen, elkészítünk egy CSS sablont, és integráljuk azt a webhelyünkbe a HTML jelölés struktúrájának megváltoztatásával, valamint a CSS és a JavaScript fájlok bevonásával:
<link rel = "stíluslap" type = "text / css" href = "/ css / style.css" /> <script src = "/ js / jquery-1.6.2.js" type = "text / javascript">szkript>
A cikk végén, az "Eredmény" részben található egy link a GitHub-tárházhoz egy projekttel, amelynek lépései megtörténtek egy egyszerű sablon integrálására.

2.3.1. Hozzon létre egy kezdőlapot

Kezdjük a vezérlővel controller_main.php, itt van a kódja:
osztály Controller_Main kiterjeszti a Controller ( függvény action_index () {$ this -> nézet-> generálás ("main_view.php", "template_view.php"); ))
Módszerbe generál a Nézet osztály egy példánya, az általános sablon és nézet fájlnevei átkerülnek az oldal tartalmához
Az index művelet mellett a vezérlő természetesen tartalmazhat más műveleteket is.

Korábban áttekintettük a fájlt általános nézettel. Vegyünk egy tartalomfájlt main_view.php:
<h1>Üdvözöljük!h1> <p> <img src = "/ images / office-small.jpg" align = "left"> <a href = "/"> OLOLOSHA CSAPATa>- egy csúcsminőségű weboldal-fejlesztési szakemberekből álló csapat, amelynek éves tapasztalata van mexikói maszkok, bronz- és kőszobrok gyűjtése Indiából és Ceylonból, barlanglemezek és szobrok, amelyeket Öt-hatszáz évvel ezelőtt készítettek az Egyenlítői Afrika mestereip>
Ez egyszerű jelölést tartalmaz PHP hívások nélkül.
A főoldal megjelenítéséhez a következő címek egyikét használhatja:

az absztrakciót megvalósító könyvtárak módszerei. Például a PEAR MDB2 könyvtár módszerei;
ORM módszerek;
módszerek a NoSQL-kel való munkához;
satöbbi.

model_portfolio.php

osztály Model_Portfolio kiterjeszti a Model (

függvény get_data () {

"A német Löwenbraü gyártó Dunkel sötét sörének promóciós helyszíne, amelyet Oroszországban a SAN InBev sörfőzde gyárt."

"A Zopo vállalat orosz nyelvű kínai telefonok katalógusa az Android OS és a hozzájuk tartozó kiegészítők alapján."

A modell vezérlő osztály a fájlban található controller_portfolio.php, itt van a kódja:
osztály Controller_Portfolio kiterjeszti a Controller ( function __construct () {$ this -> model = új Model_Portfolio (); $ this -> nézet = új nézet (); ) függvény action_index () {$ data = $ this -> modell-> get_data (); $ this -> nézet-> generálás ("portfolio_view.php", "template_view.php", $ data); ))
Változóba adat a metódussal visszaadott tömb meg van írva get_data amelyet korábban megnéztünk.
Ez a változó továbbadódik a módszer paramétereként generál, amelyeket szintén átadnak: a fájl neve a közös sablonnal és a fájl neve, amely a nézetet és az oldal tartalmát tartalmazza.

Az oldal tartalmát tartalmazó nézet a fájlban található portfolio_view.php.

Portfólió

De ebben a verzióban felvázoltam a következő osztályokat (és azok megfelelő nézeteit):

Controller_Login, amelyben egy bejelentkezés és jelszó megadásához szükséges űrlappal rendelkező nézet jön létre, miután kitöltötte a hitelesítési eljárást, és ha sikeres, a felhasználót átirányítja az adminisztrációs panelre.
Contorller_Admin indexművelettel, amelynek során ellenőrizzük, hogy a felhasználót korábban adminisztrátorként engedélyezték-e a webhelyen (ha volt, akkor megjelenik az adminisztrátori panel nézete), és kijelentkezési művelettel a kijelentkezéshez.

4. Következtetés

De az olyan webes keretrendszerek, mint a Yii vagy a Kohana, amelyek több száz fájlból állnak, nem mindig ajánlott egyszerű webes alkalmazások (például névjegykártya-oldalak) fejlesztésekor. Most egy gyönyörű MVC modellt készíthetünk, hogy ne keverjük össze a Php, Html, CSS és JavaScript kódokat egy fájlban.

Ez a cikk inkább a CMF elsajátításának kiindulópontja, mintsem valami igazán helyes példa, amelyet webalkalmazásának alapjául vehet. Talán ő is inspirált téged, és máris gondolkodsz azon, hogy megírod a saját mikrokeretedet vagy CMS-t az MVC alapján. Mielőtt azonban újból feltalálná a "blackjack és a kurvák" kerékpárt, gondold át, talán erőfeszítéseid bölcsebben irányulhatnak egy meglévő projekt fejlesztésére és közösségének segítésére?

P. S.: A cikket a megjegyzésekben hagyott néhány megjegyzés figyelembevételével írták át. A kritika nagyon hasznos volt. A válasz alapján megjegyzés: megjegyzések, személyes kérések és azoknak a felhasználóknak a száma, akik hozzáadták a bejegyzést a kedvenceikhez, a bejegyzés megírásának ötlete nem is olyan rossz. Sajnos nem lehet minden kívánságot figyelembe venni, és időhiány miatt egyre részletesebben írni ... de talán azok a titokzatos alakok fogják megtenni, akik levonják az eredeti verziót. Sok sikert a projektjeihez!

5. Válogatás a témához kapcsolódó hasznos linkekről

Ez a példa bemutatja, hogyan lehet automatikusan kijelentkezni az alapértelmezett Spring biztonsági konfigurációval.

A kijelentkezéshez csak hozzáférnünk kell a "/ logout" URL-hez a POST kéréssel.

A POST / logout űrlapba be kell építenünk a CSRF tokent is, amely védelmet nyújt a CSRF támadással szemben.

Lássuk, hogyan kell ezt megtenni.

Java Config osztály

Ne feledje, hogy a fenti konfigurációban felülbíráljuk a konfigurációt (HttpSecurity http) az alapértelmezett alap hitelesítés kihagyásával (lásd az eredeti módszert a WebSecurityConfigurerAdapter forráskódban), és űrlap alapú hitelesítést használunk. Azért tesszük ezt, mert a böngészők agresszív módon gyorsítótárba helyezik az alapvető hitelesítési információkat (az első sikeres bejelentkezés után), és nincs mód a felhasználó kijelentkezésére az aktuális munkamenet során. A legtöbb példában nem fogjuk használni az alap hitelesítési mechanizmust.

Egy vezérlő

A JSP oldal

src / main / webapp / WEB-INF / views / my-page.jsp

Tavaszi biztonsági példa

Idő: $ (idő)

Példák kipróbálásához futtassa a beágyazott tomcat-ot (az alábbi példa projekt pom.xml-ben konfigurálva):

Mvn tomcat7: futás-háború

Kimenet

Az "URI" kezdeti hozzáférése átirányítja a "/ login" címre:

Miután elküldte a felhasználónevet és a jelszót, amikor beállítottuk az AppConfig osztályt:

A "Kijelentkezés" gombra kattintva:

Példa projektre

Függőségek és alkalmazott technológiák:

spring-security-web 4.2.3.KÖZLEMÉNY: spring-security-web.
spring-security-config 4.2.3. KÖZLEMÉNY: spring-security-config.
spring-webmvc 4.3.9.KÖZLEMÉNY: Spring Web MVC.
javax.servlet-api 3.1.0 Java Servlet API
JDK 1.8
Maven 3.3.9

Szerkessze a fájlt urls.py mellékletek számla:

# url (r "^ login / $", views.user_login, name = "login"),

"django.contrib.auth.views.login"

"django.contrib.auth.views.logout"

"django.contrib.auth.views.logout_then_login"

Megjegyeztük a nézet URL-mintáját bejelentkezés a nézet használatához korábban létrehozott Belépés Django.

Hozzon létre egy új könyvtárat az alkalmazássablonok könyvtárában számlaés hívja bejegyzés. Hozzon létre egy új fájlt egy új könyvtárban, nevezze el login.html

(% kiterjeszti "base.html"%) (% block title%) Bejelentkezés (% endblock%) (% block content%)

Belépés

Felhasználónév és jelszó nem egyezik. Kérjük, próbálja újra.

Kérjük, használja a következő űrlapot a bejelentkezéshez:

Ez a bejelentkezési sablon nagyon hasonlít a korábban létrehozott sablonhoz. Django használja AuthenticationForm található django.contrib.auth.forms... Ez az űrlap megpróbálja hitelesíteni a felhasználót, és érvényesítési hibát dob, ha a felhasználónév nem megfelelő volt. Ebben az esetben hibákat kereshetünk a (% if form.errors%) paranccsal. Felhívjuk figyelmét, hogy hozzáadtunk egy rejtett elemet nevű változónak küldjön értéket következő.

Paraméter következő URL-nek kell lennie. Ha ez a paraméter meg van adva, akkor a felhasználó bejelentkezése után átirányítja a megadott URL-re.

Most hozzon létre egy sablont logged_out.html a sablonkönyvtárban bejegyzésés illessze be a következő kódot:

(% kiterjeszti a "base.html"% -ot) (% block title%) Kijelentkezett (% endblock%) (% block content%)

Kilépett

Sikeresen kijelentkezett. Újra bejelentkezhet.

Ez a sablon jelenik meg, miután a felhasználó bejelentkezett.

Az URL-minták és sablonok hozzáadása után a bemeneti és kimeneti nézetekhez a webhely készen áll a bejelentkezésre Django hitelesítési nézeteivel.

Felhívjuk figyelmét, hogy a kilátás logout_then_login szerepel a mi urlconf, nincs szüksége sablonra, mivel átirányítja a jelentkezzen be.

Most hozzunk létre egy új nézetet az irányítópult megjelenítéséhez a felhasználó számára, hogy tudjuk, mikor jelentkezett be a felhasználó a fiókjába. Nyissa meg a fájlt views.py mellékletek számlaés adja hozzá a következő kódot:

def műszerfal (kérés):

Díszítőt adunk a nézetünkbe Bejelentkezés Szükséges hitelesítési keretrendszer. Díszítő Bejelentkezés Szükséges ellenőrzi, hogy az aktuális felhasználó hitelesített-e. Ha a felhasználó hitelesítésre kerül, akkor a benyújtás végrehajtásra kerül; Ha a felhasználó nincs hitelesítve, akkor átirányítják a bejelentkezési oldalra.

Meghatároztuk a változót is szakasz... Ezt a változót arra használjuk, hogy nyomon kövessük, hogy a felhasználó melyik részleget nézi a felhasználó.

Most létre kell hoznia egy sablont az irányítópult nézetéhez. Hozzon létre egy új fájlt a sablonokban / fiókban sablonok / fiók /és hívja irányítópult.html :

(% kiterjeszti "base.html"%) (% block title%) Irányítópult (% endblock%) (% block content%)

Irányítópult

Üdvözöljük az irányítópulton.

Ezután adja hozzá a következő URL-mintát a fájl módosításához urls.py mellékletek számla:

Urlpatterns = [# ... url (r "^ $", views.dashboard, name = "dashboard"),]

Most szerkessze a fájlt settings.py:

LOGIN_REDIRECT_URL: Megmondja, melyik URL-re irányítja át a felhasználót a bejelentkezés után.
LOGIN_URL: URL, amely a felhasználót a bejelentkezéshez irányítja (például dekoratőr használatával Bejelentkezés Szükséges)
LOGOUT_URL: URL a felhasználó átirányításához a kijelentkezéshez

Most hozzáadjuk a bejelentkezési és a kijelentkezési linkeket az alapsablonunkhoz.

Ehhez meg kell határozni, hogy az aktuális felhasználó be van-e jelentkezve, vagy sem, hogy megjelenítse a felhasználó aktuális állapotának megfelelő linket. A jelenlegi felhasználó be van állítva HttpRequest köztes osztályú objektum-hitelesítés. A címmel érhető el kérés.felhasználó... A felhasználói objektum akkor is megtalálható a kérésben, ha a felhasználó nincs hitelesítve. Nem hitelesített felhasználó, a kérelemben példányként megadva AnonymousUser... A jelenlegi felhasználó hitelesítési állapotának ellenőrzésének legjobb módja a kihívás request.user.is_authenticated ()

Szerkesztés a base.html sablonban

azonosító fejléccel:

Mint látható, a webhely menü csak a hitelesített felhasználók számára jelenik meg. Ellenőrizzük az aktuális részt is, hogy hozzáadjuk a kiválasztott class attribútumot a megfelelő elemhez

hogy a menü aktuális szakaszát kiemelje a CSS segítségével. Megjeleníti a felhasználónevet és a bejelentkezési linket is, ha a felhasználó hitelesített, vagy egy bejelentkezési linket.

Nyissa meg a http://127.0.0.1:8000/account/login/ oldalt a böngészőben. Látnia kell egy belépési oldalt. Adjon meg érvényes felhasználónevet és jelszót. A következőket fogja látni:

Láthatja, hogy a Saját irányítópult szakasz kiemelve van CSS-sel, mivel van osztálya kiválasztott... Mivel a felhasználó hitelesített, a felhasználónév a fejléc jobb oldalán jelenik meg. Kattintson a linkre Kijelentkezés... A következő oldalt fogja látni:

Ezen az oldalon láthatja, hogy a felhasználó ki van jelentkezve, és ezért a webhely menüje már nem jelenik meg. A fejléc jobb oldalán található link megjelenik Belépés.

Ha egy kijelentkezési oldalt lát a Django admin webhelyéről, és nem a saját kijelentkezési oldalát, ellenőrizze az INSTALLED_APPS beállításait, és győződjön meg róla django.contrib.admin utána van számla... Mindkét sablon ugyanazon a relatív elérési úton van, és a Django sablon betöltő az első megtaláltat fogja használni.

A Django sok beépített erőforrással rendelkezik a webalkalmazások leggyakoribb felhasználási eseteihez. A regisztrációs alkalmazás nagyon jó példa, és jó dolog benne, hogy a funkciók azonnal felhasználhatók.

A Django regisztrációs alkalmazással a következő funkciók előnyeit veheti igénybe:

Belépés
Kijelentkezés
Regisztrálj
Jelszó visszaállítása

Ebben az oktatóanyagban a bejelentkezés és a kijelentkezés funkcióira összpontosítunk. A regisztrációhoz és a jelszó visszaállításához ellenőrizze az alábbi oktatóanyagokat:

Elkezdeni

Mielőtt elkezdenénk, győződjön meg arról, hogy rendelkezik-e a django.contrib.auth névvel az INSTALLED_APPS fájlban, és a hitelesítési köztes szoftverben megfelelően konfigurálva van-e a MIDDLEWARE_CLASSES beállításokban.

Mindkettő már konfigurálva van, amikor elindít egy új Django projektet a startproject paranccsal. Tehát, ha nem távolította el a kezdeti konfigurációkat, akkor mindet be kell állítani.

Abban az esetben, ha új projektet indít csak az oktatóanyag követése érdekében, hozzon létre egy felhasználót a parancssor segítségével, hogy tesztelhessük a bejelentkezési és a kijelentkezési oldalakat.

A $ python manag.py létrehozza a felsőfelhasználót

A cikk végén megadom a példa forráskódját a minimális konfigurációval.

Konfigurálja az URL útvonalakat

Először importálja a django.contrib.auth.views modult, és adjon hozzá egy URL-útvonalat a bejelentkezési és kijelentkezési nézetekhez:

a django.conf.urls fájlból importálja az URL-t a django.contrib oldalról importálja az adminisztrátort a django.contrib.auth fájlból importál nézeteket auth_views néven urlpatterns = [url (r "^ login / $", auth_views. login, név = "login"), url ( r "^ kijelentkezés / $", auth_views. kijelentkezés, név = "kijelentkezés"), URL (r "^ admin /", admin. webhely. URL-ek),]

Hozzon létre egy bejelentkezési sablont

Alapértelmezés szerint a django.contrib.auth.views.login nézet megpróbálja megjeleníteni a registration / login.html sablont. Tehát az alapkonfiguráció egy regisztráció nevű mappa létrehozása lenne, és belépne egy login.html sablont.

Minimális bejelentkezési sablont követve:

(% kiterjeszti "base.html"%) (% block title%) Bejelentkezés (% endblock%) (% block content%)

Belépés

(% csrf_token%) ((form.as_p)) (% endblock%)

Ez az egyszerű példa már érvényesíti a felhasználónevet és a jelszót, és helyesen hitelesíti a felhasználót.

A bejelentkezési nézet testreszabása

Néhány paramétert átadhat a bejelentkezési nézetnek, hogy az illeszkedjen a projektjéhez. Például, ha máshol szeretné tárolni a bejelentkezési sablont, mint a registration / login.html, akkor átadhatja a sablon nevét paraméterként:

url (r "^ login / $", auth_views. bejelentkezés, ("template_name": "core / login.html", name = "login"),

Egyéni hitelesítési űrlapot is átadhat a authentication_form paraméter használatával, ha egyéni felhasználói modellt valósított meg.

Most egy nagyon fontos konfiguráció történik a settings.py fájlban, amely az az URL, amelyet a Django sikeres hitelesítés után átirányít a felhasználóhoz.

A settings.py fájlon belül adja hozzá:

LOGIN_REDIRECT_URL = "otthon"

Az érték lehet keményen kódolt URL vagy URL-név. A LOGIN_REDIRECT_URL alapértelmezett értéke a / accounts / profile /.

Fontos megjegyezni azt is, hogy Django megpróbálja átirányítani a felhasználót a következő GET param-re.

A kijelentkezési nézet beállítása

Miután belépett a django.contrib.auth.views.logout nézetbe, Django rendereli a register / logged_out.html sablont. Hasonló módon, mint a bejelentkezési nézetben tettük, átadhat egy másik sablont, így:

url (r "^ logout / $", auth_views. kijelentkezés, ("template_name": "logged_out.html"), name = "logout"),

Általában a next_page paramétert használom, és átirányítom a projektem kezdőlapjára vagy a bejelentkezési oldalra, ha van értelme.