Quindi ora che abbiamo introdotto CSRF concettualmente,
parliamo di come
lo implementiamo effettivamente in esecuzione in Django.
Quindi, se ricordi,
non l'ho
fatto notare troppo quando l'abbiamo attraversata.
Questo è stato il mio primo modulo in cui ti ho mostrato
come i dati potevano essere
trasportati al server usando una richiesta POST.
Se guardi in alto, ho
questa piccola annotazione @csrf_exempt
e c'è una piccola importazione sopra di essa nel nostro file di viste,
e quello che stavo fondamentalmente dicendo a
Django è non farlo saltare in aria
perché non sto gestendo CSRF correttamente.
Quindi quello che
faremo è fare esattamente la stessa vista,
tranne che non avremo quella piccola cosa.
Quindi chiameremo questo modulo fallito
e lanceremo un modulo,
premeremo invio.
Tutto sembra a posto, l'unica differenza è
che non ho disattivato l'elaborazione CSRF.
Quindi su una richiesta POST,
l'elaborazione CSRF è attiva per impostazione predefinita, il
che significa che dobbiamo fare qualcosa in
modo esplicito quando stiamo facendo a mano moduli POST,
ma non l'ho ancora fatto.
Quindi questo è quello che succede se non lo fai.
Quindi si ottiene un modulo e si
digita alcune cose e si
preme Invia query e boom,
si ottiene questo messaggio Proibito, che è un 403.
Quindi, tra tutte le risposte HTTP,
abbiamo 200, che va bene,
abbiamo 302, che viene spostato,
e abbiamo 404, che non viene trovato.
403 è che non stai ricevendo questa pagina,
ma non perché io non ce l'abbia,
ma perché non sei autorizzato a farlo.
Quindi questo sta abortendo
e fermando il POST. Quindi entra,
guardi la sessione e tutto
sembrava buono tranne che il CSRF non corrispondeva.
Ora, siamo un server legittimo,
quindi quello che dobbiamo fare è aggiungere effettivamente
il CSRF al POST all'uscita, ok?
Quindi questo è esattamente lo stesso POST,
e sto facendo questo tipo di a un livello basso,
e ti mostrerò un modo molto più semplice per farlo in un minuto.
Quindi abbiamo un input nascosto.
Mi capita di sapere che csrfmiddlewaretoken
è il nome giusto per questo,
e ho solo intenzione di avere un segnaposto,
che è __token__.
E quindi quello che ho intenzione di fare è parlare con
quel middlewarecrsf get_token.
Ora, quel token è probabilmente
solo un numero seduto nella sessione,
ma non ho bisogno di saperlo.
Dico solo: «Ehi,
dammi il gettone per la richiesta attuale».
La richiesta è, ovviamente, tutti i dati che arrivano,
hanno la sessione, c'è tutto il resto.
Allora, «Ehi, dammi quel gettone».
Questa è una grande stringa lunga,
che è in realtà solo un grande numero casuale lungo,
una grande stringa casuale lunga.
E poi quello che ho intenzione di fare è prendere qualsiasi cosa sia
quel grande numero casuale,
e ho intenzione di sostituire questo piccolo pezzo con
un semplice sostituto, e poi ho intenzione di mandarlo fuori.
Quindi questa volta, quando andiamo a quella pagina,
vedrete che ora abbiamo un tipo di input uguale nascosto,
nome uguale crsfmiddlewaretoken,
e poi il grande middlewaretoken lungo,
qualunque cosa sia. E poi ora quando lo inviamo,
raggruppa sia l'ipotesi che il middlewaretoken,
e in realtà raggruppa anche l'invio se
ha un nome e lo invia come dati POST.
Quindi ora quando si scarica fuori, vedi, oh,
beh hai indovinare uguale a 42 e csrfmiddleware.
Ora, quando arrivera' a questo punto,
non faremo il controllo qui.
Il controllo è stato eseguito prima dell'inizio della vista.
E quindi se torniamo alla vista qui,
il controllo è fatto prima che arrivi a qui,
quando stai inviando da urls.py a questo
e dice, «Non mi hai detto di
non fare CSRF e non è fatto correttamente,
quindi ti farò saltare in aria.»
Quindi, se sta per funzionare, ha gia' funzionato.
Il fatto che siamo venuti qui e stiamo
scaricando questa roba dal POST,
è come se la vedessimo,
ma sarebbe saltato in aria prima che
fosse arrivato al nostro codice a quel punto.
Ma lo otteniamo e lo vediamo come dati POST.
Non ne abbiamo bisogno perché se
proprio per il fatto che la nostra visione
è in esecuzione significa che
l'elaborazione CSRF ha avuto successo, ok?
E ancora, il sistema canaglia deve
in qualche modo mettere le mani su questo,
il numero effettivo del CSRF,
e questo cambia ogni volta che accedi.
E letteralmente potrebbe cambiare
ogni ora o giù di lì,
e quindi è un numero difficile da
indovinare ed è un numero difficile da mettere le mani su.
Ora, quella cosa manuale
non è il modo più semplice per inserirlo,
c'è un modo semplice in CSRF. Dici semplicemente,
quindi ecco il nostro modulo, ecco la nostra forma di barra.
Faccio tutte le cose che voglio fare e poi uso il codice,
si chiama tag template.
Quando hai abilitato CSRF nel tuo Python,
hai un tag template di csrf_token
e questo emette l'input,
il tipo è uguale a nascosto,
il nome giusto e tutta quella roba.
Quindi tu, come sviluppatore che usa i modelli,
non devi sapere nulla a riguardo, ok?
Ed è così che facciamo CSRF.
E l'unica altra cosa che abbiamo è
un gioco di indovini e poi
passeremo un messaggio e lo faremo tra un po'.
Useremo questo per un
sacco di piccoli esempi.
Quindi tipo di ricordare questo particolare modello guess.html,
ma la chiave in questo momento di cui stiamo parlando
è il fatto che abbiamo questo token CSRF in.
Ora, ho intenzione di scrivere un sacco di
indovinare giochi, e in questi giochi indovinando
in realtà ho intenzione di iniziare a controllare le ipotesi.
Quindi ho intenzione di avere una funzione in questa vista
che si chiama checkguess.
Ed è abbastanza semplice, restituisce una stringa o falso.
Se l'ipotesi è una cosa reale non falsa,
controlliamo se è troppo bassa, troppo alta,
o giusto in tempo,
O se non si converte,
se questa ipotesi int genera un traceback, beh,
allora diremo cattivo formato per indovinare
e poi solo perché probabilmente proviene dall'utente,
siamo per sfuggirlo e poi rimandarlo indietro.
Quindi,
qualunque cosa faccia, manderemo indietro un
bel messaggio.
E così ecco un semplice gioco di indovinare che stiamo andando a fare,
e quindi stiamo usando una vista basata sulla classe questa volta.
Naturalmente, estendiamo la vista di classe,
e ricordiamo come
funziona questo è che non è solo una funzione,
in realtà abbiamo due metodi.
Uno è una richiesta GET,
e il get viene chiamato quando stiamo ricevendo una richiesta GET,
e il post viene chiamato
quando stiamo ricevendo una richiesta POST.
Solo questo è uno dei buoni motivi per farlo.
In realtà non devi dire, se è un GET,
fai una cosa,
se è un POST, fai un'altra cosa.
Abbiamo solo due metodi e
Django indirizza correttamente le richieste, ok?
E così questo sarà un modulo POST.
Quindi al get, eseguiamo il rendering senza messaggi,
c'è, e abbiamo un token CSRF
che si spegne, quindi lo rendiamo.
Quindi faremo clic sul pulsante
in modo che questo rendering qui produrrà questa pagina.
Quindi digitiamo nell'ipotesi
di 42 e premiamo Invia query,
e poi che raggruppa tutto, fino a includere CSRF,
e va al POST.
Ora il CSRF, finché lo inseriamo in quel modello,
non ci interessa perché prima
che quel metodo post venga attivato,
CSRF è stato elaborato e otteniamo un
403 se il CSRF non è giusto.
Quindi se torniamo qui e non lo inseriamo
e tu esegui questo codice,
il csrf_token, non lo
metti, quando colpisci questo,
non arriverà mai al POST,
esplode in rotta verso il POST
se il CSRF non accade.
Ma abbiamo la CSRF ed è tutto automatico,
lanciamo quella riga all'interno del
nostro modulo ed è tutto quello che dobbiamo fare.
Quindi abbiamo messo 42 in,
abbiamo premuto Invia query,
passa CSRF, entra in.
Quindi prendiamo l'ipotesi dai dati POST.
Chiamiamo il mio piccolo messaggio di
controllo, checkguess, che
mi dara' quel piccolo messaggio se e'
troppo basso, troppo alto, o qualche tipo di altro errore.
E poi ho intenzione di passare in un contesto,
il messaggio stringa ha quella stringa,
e se poi andiamo,
ce l'ho qui, no. Ce
l'ho quassù.
Quindi esce il messaggio.
Quindi questo, noterai che ho circondato questo da un if,
in modo che se il messaggio è falso o non presente,
allora non emette nulla.
Ma se lo è, in realtà mette fuori il messaggio.
E così viene fuori l'ipotesi,
e quindi questo è
come appare quando facciamo una richiesta GET, giusto?
Vediamo questo, poi stiamo andando a vedere
tutte queste cose, stiamo andando a
digitare il nostro numero in, stiamo andando a premere Invia query,
e poi sta per accendere una richiesta POST.
Quindi tornerà nella richiesta POST,
otterrà l'ipotesi dai dati POST.
Lo controllerà,
e poi passerà il messaggio.
E quindi il messaggio verra' fuori,
e poi torneremo quella pagina.
E così si sta andando a vedere
qualcosa come Congratulazioni 42.
Così che ha preso, che era parte del POST,
e così ora abbiamo fatto un gioco di indovinare di successo.
Quindi la prossima volta parleremo,
proprio quando riusciamo a far funzionare qualcosa,
c'è sempre qualcosa che dobbiamo dire,
oh, ma c'è un piccolo dettaglio che ci siamo dimenticati.
Quindi il prossimo, parleremo di POST e Refresh,
che è un piccolo problema che dovremo solo risolvere.
[ MUSIC]