Tempo per il terzo incarico in questo corso.
In questo modulo, abbiamo esplorato l'autenticazione utente in molti dettagli.
Ora, in questo incarico,
lavoreremo ulteriormente sull'autenticazione dell'utente.
Aggiungeremo ancora un'altra categoria di account chiamati come amministratore.
Un account Admin è un super account che ha
molti privilegi per eseguire varie operazioni.
Un normale account utente può eseguire solo determinate operazioni sul nostro server.
Allo stesso modo, una richiesta non registrata proveniente da un client
che non è connesso può eseguire solo determinate operazioni sul nostro server.
Ora, stiamo andando a modificare il nostro server in modo
che ottenere operazioni possono essere eseguite da chiunque.
Non è necessario accedere al sistema per eseguire operazioni di recupero
sui vari endpoint API di riposo tranne l'invio di commenti.
Per le operazioni rimanenti sugli endpoint API restanti,
le operazioni POST put and delete,
queste saranno limitate per essere eseguite solo da utenti amministratori,
un utente ordinario non può eseguire queste operazioni.
Ovviamente, non vuoi che un utente ordinario invii nuovi piatti, promozioni o
informazioni sui leader, o modifichi le informazioni esistenti
o addirittura elimini queste informazioni esistenti.
Questo dovrebbe essere il privilegio solo dell'amministratore di sistema per il nostro server.
Inoltre, ci assicureremo che un utente ordinario possa
pubblicare commenti su piatti specifici, che è accettabile.
Allo stesso modo, un utente ordinario può aggiornare ed eliminare i commenti che ha pubblicato.
Altri utenti o anche l'amministratore non possono aggiornare o eliminare i commenti pubblicati da un altro utente.
Quindi, questa è un'altra restrizione che metteremo nel nostro server.
Ora, andiamo avanti ed esaminiamo come stiamo andando a
implementare questo e come esattamente il nostro server esegue queste operazioni.
Prima di tutto, vi illustrerò come si
creerebbe un account amministratore nel vostro sistema.
Ti renderai conto che dobbiamo andare dietro
le quinte per creare un account amministratore semplicemente perché,
non vogliamo che un account amministratore venga creato eseguendo
l'operazione di registrazione sul nostro account utenti/registrazione.
Questo lascerà il nostro server vulnerabile agli attacchi.
Quindi, un account amministratore può essere impostato solo
dietro le quinte accedendo direttamente al database.
Quindi, diamo un'occhiata a come facciamo
questo nell'illustrazione che vi mostrerò subito dopo.
Ora, per esaminare
il nostro database, lasciatemi avviare Mongo Ripple alla riga di comando,
quindi andare alla cartella confusione e quindi lasciatemi
esaminare gli utenti che sono registrati nel mio database in questo momento.
Quindi, puoi vedere che ho solo un utente registrato.
Quindi, lasciami impostare due account aggiuntivi,
uno per un utente ordinario
e uno che sarà un amministratore.
Quindi, registreremo l'amministratore e il secondo utente anche dal nostro punto di registrazione, in
seguito torneranno al Mongo Ripple e quindi imposteranno l'account amministratore in
modo esplicito modificando il record nel nostro database.
Andando al pin Postman,
mi permetta di iscrivere due utenti aggiuntivi.
Quindi, in precedenza avevamo firmato un utente con questo nome,
quindi ho intenzione di registrare un altro utente nel mio sistema,
e così, un secondo utente è ora registrato con successo.
Ora, lasciami registrare anche un account amministratore.
Quindi, per l'account admin,
imposterò il nome utente come admin e quindi iscriverò un utente admin.
Quindi, vediamo che ora abbiamo aggiunto due nuovi account al nostro sistema.
Andando al Mongo Ripple,
fammi ripetere di nuovo il
db.user.find () e lasciami fare abbastanza in modo che sembri più facile da leggere.
Quindi, quando faccio questo,
puoi vedere che abbiamo un account amministratore qui con il nome utente come amministratore.
Ignorare il nome e il cognome,
imposterò questo nome e cognome per essere lo stesso per tutti e tre.
Quindi, abbiamo l'altro account utente che ho impostato con il nome utente qui,
e il terzo account utente che abbiamo già avuto nel nostro database.
Quindi, ora abbiamo tre account utente;
due account utente qui,
e un account amministratore.
Ora, naturalmente, vedrai che negli account utente,
abbiamo questo flag chiamato come flag admin che è impostato su false per
qualsiasi account che è registrato su questo/users/signup endpoint.
Questo è il modo predefinito in cui è necessario impostare gli account.
Non è possibile consentire a un utente di configurare un account amministratore
eseguendo qualsiasi operazione direttamente sull'endpoint API di riposo.
Invece, andremo dietro le quinte e poi nel Mongo Ripple,
ho intenzione di modificare questo record per l'utente admin
dicendo db.users.update e poi
forniremo il nome utente come admin qui.
Quindi, stiamo per aggiornare il record di versi e poi diremo {$ set:
ricorda come stavamo manipolando il mongoDB quindi
diremo {$ set: {"admin»: «true»}.
Quindi, quello che stiamo facendo qui è che stiamo
cercando questo account utente con il nome utente admin,
e quindi stiamo impostando il flag admin a true
qui utilizzando l'opzione $ set.
Quindi, questo è il modo in cui vorremmo aggiornare un account per essere un account amministratore.
Quindi, vedi che questo ha modificato i risultati.
Quindi, controlliamo di nuovo i conti.
Ora, quando controlli l'account,
vedrai che per l'account admin,
il flag admin è ora impostato su true,
quindi questo è il modo in cui finirai per creare un account admin.
Ora, l'account Admin come ci aspetteremmo ha privilegi aggiuntivi.
Quindi, una volta completata questa assegnazione,
noterai che l'operazione get può essere eseguita da qualsiasi utente
su/dishes/dishes/aspecificdishendpoint/promotions
e il/promotions/specificpromotionendpoint e allo stesso modo,
anche per i leader in punti.
Ma le
operazioni POST, put ed delete su questi endpoint possono essere eseguite solo dagli utenti amministratori.
Ora, in aggiunta, l'endpoint commenti,
consentiremmo solo un utente registrato che ha effettuato l'
accesso per accedere ai commenti per un piatto specifico,
permetteremo a un utente connesso di pubblicare commenti.
Abbiamo già impostato questo nell'esercizio in modo che,
quando l'utente pubblica il commento,
abbiamo assicurato che verifichiamo
l'autenticità dell'utente e poi quando il commento viene pubblicato,
abbiamo impostato l'ID autore per il commento utilizzando l'ID utente.
Quindi, l'abbiamo già completato.
Ma ora, in aggiunta,
per le operazioni put e delete sui commenti,
solo l'utente che ha inviato il commento specifico sarà
autorizzato a eseguire operazioni di put ed eliminazione sui propri commenti.
Qualsiasi altro utente non può modificare i commenti di qualcun altro.
Allo stesso modo, anche l'amministratore non può modificare i commenti di qualcun altro
o eliminare il commento di qualcun altro.
Quindi, questa è la seconda parte di questo incarico che farai.
La terza parte è che un amministratore può interrogare
il punto finale /users e chiedere l'elenco degli utenti registrati,
nessun altro utente ordinario può fare questa query.
Quindi, questa è l'altra restrizione che metteremo lì dentro.
Ora, per verificare che un utente sia un amministratore,
verificheremo prima che l'utente sia un utente registrato.
Quindi, la funzione utente di verifica che abbiamo già implementato nel
authenticate.js dovrebbe essere applicata anche dove è necessario verificare l'amministratore.
Innanzitutto, si controlla che sia un utente verificato, in seguito,
si introdurrà un'altra funzione chiamata VerifyAdmin nel
file authenticate.js che controllerà per assicurarsi che l'utente sia un amministratore.
Ora, per verificare se un utente è un amministratore,
tutto ciò che devi fare è controllare il rec.user che si trova
sull'oggetto richiesta rec.user lì,
verificare se il flag admin è true o meno.
Se il flag admin è true,
si consentirà il normale processo di procedere ulteriormente al [inudibile] accadere.
Se l'utente non è un amministratore,
verrà generato un errore e verrà restituito un messaggio di errore al lato client.
Quindi, è così che stiamo andando a gestire l'account degli utenti admin.
Ora, quando un utente sta cercando di modificare o eliminare i propri commenti,
dobbiamo verificare che l'autore del commento sia
lo stesso dell'utente che sta tentando di modificare il commento.
Ora, il rec.user ha anche il campo ID,
quindi è necessario incrociarlo con il campo autore del commento.
Se questi due corrispondono,
allora si consentirà all'utente di eseguire le operazioni put o delete.
Se non corrispondono
, non consentirai le operazioni put o eliminazione su quel commento specifico.
Quindi questo è l'altro aspetto che stai per
implementare come parte del tuo terzo incarico.
Diamo un'occhiata a come tutte queste cose funzionano
utilizzando Postman per eseguire varie operazioni sul nostro server.
Tornando a Postman,
fammi prima eseguire un'operazione GET sui
piatti per controllare solo cosa c'è nel mio database.
Quindi, se eseguo un'operazione GET sui piatti,
nota che non sto mettendo alcuna autenticazione nell'intestazione.
L' operazione GET è consentita da chiunque.
Quindi, quando eseguo l'operazione GET,
posso vedere che ho già un piatto con un commento già in atto in quel piatto.
Questo commento è già stato pubblicato da questo utente.
Quindi, abbiamo già un piatto nel sistema lì.
Quindi, questo va perfettamente bene,
ho intenzione di cancellare il piatto.
Ora, per cancellare il piatto,
ovviamente quell'operazione non può essere eseguita da un utente ordinario.
Quindi, lasciami accedere come,
in modo da poter vedere che sto effettuando l'accesso come utente normale.
Quindi, lasciami accedere come utente normale.
Quindi, quando effettuerò il login, otterrò il token.
Quindi, ho intenzione di copiare questo token e salvarlo.
Ora, che ho il mio token,
fammi eseguire un'operazione DELETE sui piatti.
Quindi, quando vado all'operazione DELETE.
Quindi, lasciami selezionare questo GET e quindi eseguire un'operazione DELETE con i piatti.
Nell' intestazione, lasciami includere l'autorizzazione qui e noterai
che quando incolliamo la richiesta e quindi inviamo l'autorizzazione DELETE,
noterai che ritorna immediatamente con questo messaggio qui,
come puoi vedere nell'anteprima,
dice «Non sei autorizzato a eseguire questa operazione! «
Quindi il codice di errore è 403 proibito.
Quindi, questo è un messaggio che è stato generato
dalla funzione VerifyAdmin che si sta per implementare come parte di questo esercizio.
Quindi, se l'utente non è un amministratore,
questo è il messaggio che il tuo VerifyAdmin
genererà e non consentirà alla richiesta di andare oltre quel punto.
Quindi, puoi vedere che ho chiuso l'operazione DELETE.
Ora, come si fa?
Nel tuo codice, hai visto che per applicare VerifyUser,
impostiamo Authenticate.verifyUser nelle
operazioni POST, PUT e DELETE.
Ora, puoi concatenare il middleware uno dopo l'altro.
Quindi, possiamo dire Authenticate.VerifyUser virgola
e quindi seguendo che puoi dire Authenticate.VerifyAdmin,
per applicare VerifyAdmin subito dopo VerifyUser.
Quindi, se si desidera che un'operazione sia limitata solo all'amministratore,
eseguire prima la parte VerifyUser e quindi immediatamente dopo,
applicare il middleware VerifyAdmin.
Subito dopo. Quindi, se questi due controlli,
passano con successo, allora andrai a eseguire l'operazione.
Se il controllo VerifyAdmin non riesce,
si restituirà questo messaggio di errore come si vede
qui e quindi interrompere l'operazione che parte.
Quindi, restituirai il prossimo errore dal tuo VerifyAdmin,
se l'utente non è un amministratore.
Quindi, ti ho dimostrato come userai
l'account degli utenti admin per limitare le operazioni per operazioni
PUT, POST e DELETE.
Stessa cosa, anche le operazioni POST e PUT non saranno consentite su nessuna di queste n parti.
Ora, lasciatemi dimostrare l'altro aspetto qui.
Quindi, hai visto che lì dentro,
quando eseguiamo l'operazione GET,
hai visto che c'era già un commento che è stato pubblicato dal nome utente Jogesh,
il primo utente che si trova nel mio sistema.
Ora, ho intenzione di accedere come l'altro utente.
Quindi, accederò come nel mio secondo account che è Muppala e poi quando accedo,
ottengo di nuovo il token.
Quindi, lasciami prendere questo gettone qui.
Fammi copiare questo token.
Ora, quello che ho intenzione di fare è fare un GET sui piatti localhost.
Quindi, lasciami fare un GET sui piatti localhost per mostrarti il commento specifico qui dentro.
Quindi, questo particolare commento con questo ID.
Quindi, quello che faro' e'
copiare quel documento d'identita'.
Ho anche intenzione di copiare l'ID commento da qui e ho intenzione di eseguire
un'operazione DELETE su questo piatto specifico
e ricordare che abbiamo
la barra commenti barra e quindi questo particolare ID commento.
Ora, ricorda che questo commento è stato pubblicato da questo nome utente,
ma ora ho effettuato l'accesso a me stesso come l'altro utente con un nome utente diverso.
Quindi, quando ora eseguo l'operazione DELETE usando l'altro account,
noteresti immediatamente che qui dice:
«Non sei autorizzato a cancellare questo commento! «
Poi dice 403, stessa cosa.
Se provi a eseguire un'operazione PUT su quel commento specifico connesso come un altro utente
, dirà: «Non sei autorizzato ad aggiornare questo commento!»
Quindi, sia PUT, DELETE che UPDATE del commento di qualcun altro non sono consentiti.
Quindi ora, lasciami accedere come amministratore a questo punto e poi lasciami provare a eliminare
quel particolare commento e vedrai che verrà generato lo stesso messaggio.
Quindi, anche un amministratore non può eliminare o aggiornare i commenti di qualcun altro.
Quindi, per accedere come amministratore,
lasciami andare nel POST qui e poi lasciami accedere come amministratore.
Ora, ricorda che questi token saranno validi per 33.600 secondi.
Quindi, è possibile salvare questi tre token che si generano per i tre utenti.
Quindi, non è necessario continuare ad accedere come quel particolare utente.
Finché si utilizza il token giusto nell'intestazione,
le operazioni si eseguiranno perfettamente identificando i tre diversi utenti.
Quindi, lasciami accedere come amministratore qui.
Quindi, quando accedo come amministratore,
ottengo il token qui.
Quindi, ho intenzione di copiare e salvare questo token.
Ricorda solo quale token appartiene a chi quando fai una copia di questo.
Ora, tornando a questo, elimina l'operazione di commento.
Andrò nell'intestazione e poi cambierò questo nel token per l'
amministratore e quindi proverò a eseguire la stessa operazione DELETE e poi vedrai
che anche l'amministratore non è autorizzato a eliminare il commento pubblicato da un altro utente.
Questo è perfettamente accettabile.
Ma proviamo a eliminare lo stesso commento,
da questo utente che ha creato
quel commento e vedresti che questo può essere fatto con successo.
Quindi, eseguiamo quell'operazione.
Quindi, per farlo, tornerò indietro e recupererò il token che
ho per il primo utente e quindi cambierò il campo Autorizzazione.
Ora, per questa operazione DELETE,
cambierò questo in portatore,
e quindi questo è il token per il primo utente con il nome utente Jogesh.
Quindi, quando provo a eliminare quel commento,
noterai che il commento è ora eliminato con successo.
Quindi, come puoi vedere dai passaggi,
il commento può essere eliminato solo dall'utente che ha creato quel commento.
Ora, il passo successivo,
quando facciamo l'operazione DELETE sui piatti,
abbiamo visto in precedenza che se abbiamo fatto l'operazione DELETE come un utente ordinario,
si ottiene un messaggio che dice,
«Non si è autorizzati a eseguire questa operazione!»
Quindi, cambierò questo token nel token dell'amministratore e poi
mostrerò che un amministratore può eseguire l'operazione DELETE sui piatti e sul piatto.
Quindi, andando in questa richiesta,
lasciami cambiare il token per essere il token per l'utente admin.
Quindi, quando eseguo l'operazione DELETE come utente amministratore,
noterai che l'operazione DELETE ha
esito positivo e quindi risponderà con il messaggio qui.
Ora, quando eseguo un GET sull'endpoint dei piatti,
noterai che le operazioni GET mostrano che i miei piatti sono stati svuotati.
Ora, l'altra operazione che implementerai anche in questa assegnazione,
è che possiamo fare un'operazione GET sull'endpoint degli utenti barra.
Pertanto, quando si esegue un'operazione GET sull'endpoint degli utenti barra,
si noterà che se non si è un utente autorizzato,
si dirà che non si è autorizzati a eseguire questa operazione.
Quindi, localhost: 3000/utenti/endpoint,
ora stai per consentire che questo venga eseguito solo dall'amministratore.
Quindi, se un utente ordinario,
se si accede come utente ordinario con l'intestazione,
non sarà consentito eseguire questa operazione.
Ora, lasciami cambiare questo token per il token
fuori dall'amministratore e poi vedrai che
l'amministratore sarà autorizzato a eseguire questa operazione.
Quindi, andando al GET,
lasciami cambiare questo token nel token per
l'utente admin e quindi quando eseguo l'operazione GET su quello, restituisce.
Come si può vedere, i tre utenti che sono registrati nel mio sistema,
mostra il numero utente uno, il
numero utente due, e il numero utente tre.
Ovviamente, si noti che l'hash e il salt vengono rimossi,
quando il messaggio viene restituito dal lato server al lato client.
Quindi, le informazioni sull'hash e il sale non saranno mai rivelate all'esterno.
Quindi, Mongos si prenderà automaticamente cura di
filtrare tali informazioni prima che restituisca le informazioni dell'utente.
Quindi, perché non dovresti rivelare le
informazioni hash e sale al mondo esterno.
Quindi, questo è il tre account utente informazioni che viene restituito.
Pertanto, questo viene restituito solo se si esegue l'operazione GET
sull'endpoint degli utenti barra come utente amministratore.
Se si esegue la stessa richiesta di qualsiasi altro utente,
ciò non sarà consentito.
Quindi, di nuovo controllerai prima,
VerifyUser e quindi controllerai VerifyAdmin e solo se si tratta di un amministratore,
allora questa operazione può essere eseguita su questo punto finale.
Quindi, questi sono tutti i vari compiti che farai come parte di questo compito.
I dettagli di come questi devono essere fatti sono documentati nelle istruzioni di assegnazione.
Quindi, leggere le istruzioni prima di procedere al completamento del terzo incarico.
Divertiti a completare il terzo incarico.