Nell'esercizio precedente,
abbiamo visto quanto è stato facile per noi configurare e quindi
impalcatura un server destinatario utilizzando il framework LoopBack.
Vediamo che questo framework LoopBack supporta un intero spettro
degli endpoint destinatario e
tutte le operazioni degli endpoint destinatario automaticamente per noi,
quando abbiamo impalcato la nostra applicazione.
In questo esercizio, vedremo come possiamo collegare il
nostro server LoopBack a un database back-end,
o MongoDB in questo caso,
e vedremo anche come possiamo impostare vari controlli di accesso sugli endpoint destinatario.
Quindi, utilizzando i controlli di accesso,
possiamo specificare che tipo di operazioni possono essere eseguite sugli endpoint del destinatario
e chi sarà autorizzato a eseguire tali operazioni.
Ad esempio, un utente non autenticato o un ospite può
accedere solo alle informazioni o eseguire un'operazione get sugli endpoint del destinatario,
un utente autenticato sarebbe in grado di fare lo stesso,
ma solo un amministratore sarebbe in grado di scrivere dati nel mio server.
Quindi, qualsiasi operazione put, post ed delete può essere eseguita solo da un amministratore.
Lungo la strada vedremo anche come possiamo impostare un account admin nel nostro server LoopBack,
e quindi configurarlo in modo che
solo l'utente amministratore sarà autorizzato a eseguire queste operazioni.
Quindi questo è dove LoopBack ci permette di definire qualcosa
chiamato ruoli associati a vari utenti.
In questo modo a ciascun utente può essere assegnato un ruolo.
Ad esempio, puoi parlare di un utente ordinario,
un amministratore, un super amministratore e così via.
In questo modo è possibile suddividere il set di utenti in vari gruppi
e quindi assegnare loro vari ruoli.
Inoltre vedremo come il modello utente incorporato può essere ulteriormente personalizzato,
all'interno della nostra applicazione LoopBack,
e come possiamo costruire un altro modello in cima al modello utente,
e quindi utilizzare il modello utente come classe base
e sviluppare un modello di livello superiore chiamato il modello cliente,
che ci permette di memorizzare informazioni aggiuntive per ciascuno
dei clienti che accederanno al nostro sito.
Quindi, esploriamo alcune di queste funzionalità di LoopBack in questo esercizio.
Per iniziare a questo esercizio,
la prima cosa che vorrei che tu facessi,
è avviare il tuo server MongoDB.
Quindi eccomi qui in un'altra scheda terminale nella mia cartella MongoDB,
dove ho configurato il mio server MongoDB in precedenza,
che è stato utilizzato dal mio server Express Plus MongoDB negli esercizi precedenti.
Quindi lasciami avviare il server MongoDB digitando
MonGod meno i dati della parte D-B
in questa cartella e quindi avviare il mio server MongoDB.
Ora, ho intenzione di collegare il mio server LoopBack al mio server MongoDB.
Quindi andando nella mia cartella del server LoopBack qui,
devo richiedere il tipo di origine dati L-B.
Questo ci permetterà di configurare l'origine dati per il nostro server LoopBack.
LoopBack stesso può connettersi contemporaneamente a più origini dati se
lo si sceglie, e supporta vari tipi.
Supporta database My Cycle, supporta MongoDB,
supporta Cloudant che è anche un altro database di documenti,
supporta Oracle e molti altri tipi di database.
Quindi, puoi facilmente configurarlo.
In questo esempio, ho intenzione di configurare il mio server LoopBack
per parlare con il mio MongoDB nel back-end.
Quindi, al prompt,
se digitiamo L-B origine dati,
ci chiederà informazioni.
Quindi la prima cosa che ci chiederà è il nome dell'origine dati,
e quindi configurerò questo nome dell'origine dati come MongoDB,
e quindi mi chiederà di selezionare il connettore.
LoopBack utilizza connettori per connettersi a vari database dietro le quinte.
Quindi, come puoi vedere, il DB in memoria che è quello che
hanno appena usato nell'esercizio precedente,
ma ovviamente il DB in memoria significa che una volta arrestato il server,
tutti i valori saranno spariti,
e quindi non è una memorizzazione di dati persistente.
Quindi qui vedete i vari tipi di database che StrongLoop supporta qui.
Così si può vedere la lunga lista dei vari database che sono supportati.
Quindi puoi vedere che supporta Cassandra, Redis,
avevamo brevemente fatto riferimento a questi quando abbiamo parlato di database NoSQL, MongoDB,
My SQL, PostGres, Oracle
e anche direttamente ad altri server API Rest ai server SOAP,
Coachbase e così via.
Quindi vedete che ci fornisce
una lunga lista di vari tipi di fonti di dati da lì,
il nostro server LoopBack può leggere nelle informazioni.
Nel mio caso, ho intenzione di utilizzare il server MongoDB, quindi ho
intenzione di impostare il connettore MongoDB.
Quindi, quando lo faccio,
LoopBack installerà automaticamente il connettore MongoDB per noi,
e quando chiede l'URL della stringa di connessione,
lo lasceremo vuoto perché gli permetteremo di utilizzare il modo standard di configurazione.
Quando chiede l'host diremo
localhost perché stiamo eseguendo il nostro MongoDB sullo stesso computer.
In caso contrario, si specifica
il nome host del computer su cui si è in esecuzione MongoDB.
Poi il prossimo è il numero di porta e stiamo
usando il nostro numero di porta standard MongoDB 27017,
e chiederà anche il nome utente e la password se richiesto,
e in questo momento il mio MongoDB è in esecuzione senza dover
fare alcuna autenticazione, quindi lascio il nome utente e la password vuoti,
e il nome del database.
Il nome del database sul server MongoDB che è in esecuzione dietro le quinte,
il nome del database c'è confusione.
Se ricordi che è il nome del database che hanno impostato sul nostro server MongoDB.
E poi ci chiederà se dovrebbe installare il connettore LoopBack,
e dirò di sì,
e in realtà andrà avanti e installare il modulo NPM che accede
al connettore LoopBack al database MongoDB.
E una volta fatto,
il mio connettore Loopback è installato qui in modo da poter vedere che questa è la versione 1.18.1
e il mio server LoopBack è tutto pronto per parlare con il mio MongoDB.
Ora, prima di procedere
in avanti, nell'esercizio precedente non configuro davvero alcuni modelli
e quindi li specifico da archiviare nel DB,
dovrò andare e aggiornarli per memorizzare i loro dati nel mio MongoDB.
Quindi, andiamo e reimpostiamo rapidamente il nostro codice per il server LoopBack.
Questo ci offre anche l'opportunità di esaminare
ciò che il mio server Loopback stesso ha configurato in questa cartella.
Aprendo la cartella LoopBack nel nostro editor,
puoi vedere che Loopback ha già
impalcato un sacco di file in questa cartella.
Il package.json naturalmente contiene
tutti i relativi moduli NPM che sono stati configurati qui fuori,
e qui dentro puoi vedere che LoopBack stesso ha configurato il modulo NPM di LoopBack,
il modulo di avvio LoopBack e in
particolare lasciatemi attirare la vostra attenzione sul loopBack MongoDB ,
che avevamo appena installato poco fa, e molti altri.
In particolare la configurazione per il server Loopback è tutta
memorizzata principalmente nei file Json qui,
con javascriptcore aggiuntivo ogni volta che richiesto.
Cercheremo la personalizzazione del codice javascript un po 'più tardi.
Permettetemi di attirare la vostra attenzione su questa cartella chiamata comune.
In questa cartella comune,
vedrai tutti i modelli che abbiamo configurato in precedenza.
Quindi vedrai che abbiamo i file Dishes.json.
Quindi, quando apri il file dishes.json, vedi come LoopBack
memorizza tutte le informazioni sul modello di piatti che hai appena creato,
quindi ha il nome, la base
e alcuni altri valori qui che richiede.
E poi guarda le proprietà e come tutte le proprietà sono memorizzate qui.
Quindi vedi alcune cose che sono molto facili da
riconoscere che sono nel file dishes.json.
Allo stesso modo, i leaders.json e le promotions.json.
Il file dishes.js è grande,
possiamo aggiungere un codice di personalizzazione aggiuntivo per i piatti,
ma in questo momento non lo faremo,
e quindi lo lasceremo così com'è.
Quindi questo è dove è possibile aggiungere un codice aggiuntivo che potrebbe
essere necessario eseguire quando si accede al punto finale dei piatti della barra.
Ma adesso lo lasceremo vuoto per il momento.
Ora diamo un'occhiata anche alla cartella del server qui.
E la cartella del server,
in particolare lasciatemi attirare la vostra attenzione sul file datasources.json qui.
Nel file sources.json,
tutte le diverse origini dati verranno configurate qui.
Quindi in questo momento, abbiamo solo il DB che è
il database DB in memoria che LoopBack per impostazione predefinita configura,
e quindi il MongoDB che abbiamo appena configurato,
assorbito solo le informazioni che l'input
è stato memorizzato in quelle origini dati, file json.
Quindi, vedrai che LoopBack stesso funziona configurando tutti questi file
che il framework LoopBack stesso fa uso di quando
avvia il server API di riposo basato su Loopback.
Andiamo nel file config.json modello qui.
Il file config.json modello stesso
memorizza molte informazioni qui che sono utili per noi,
ma qui, entriamo e modifichiamo alcune cose.
Quindi, in questo, vedremo che ci sono di nuovo per i piatti,
promozioni e leader, l'origine dati è stato configurato come DB.
Quindi lo modificheremo a MongoDB qui.
Non solo per questo,
cambieranno anche quello per le promozioni, e anche i leader
, il che significa che tutti e tre trarranno i loro dati dal MongoDB.
Inoltre, per il ruolo definito qui.
Conserveremo anche a MongoDB.
Vedremo molto presto come faremo uso del ruolo,
e anche il RoleMapping qui.
Capiremo il motivo di questi due tra poco.
E poi, ACL, gli elenchi di controllo di accesso,
questi saranno anche memorizzati in MongoDB.
E poi, l'utente, anche,
lo memorizzeremo in MongoDB,
e poi lo lasceranno lì.
Quindi, queste sono le modifiche che dovresti fare
al file model-config.json e quindi salvare le modifiche.
Come ho accennato in precedenza, Loopback per impostazione predefinita,
supporta questo modello chiamato, utente,
che viene utilizzato per supportare l'autenticazione utente.
Il modello utente stesso memorizza solo tre proprietà diverse.
Il nome utente, l'indirizzo e-mail
e le informazioni relative alla password.
Ora, se vogliono avere
un modo più elaborato di memorizzare informazioni aggiuntive sugli utenti.
Quindi possono sottoclasse questo modello di base utente
e quindi farne uso.
Quindi, in questo passaggio successivo,
creerò un altro modello chiamato, il modello cliente,
che utilizzerà l'utente come modello di base per il suo funzionamento.
E il modello cliente stesso memorizzerà ulteriori informazioni sugli utenti.
Quindi, nel modello cliente,
memorizzerò le cose come il nome,
il cognome e l'immagine per l'utente e così via.
Quindi, il cliente agirà esattamente come il modello utente,
che già viene fornito con il proprio set di metodi.
E così il modello utente viene utilizzato per l'autenticazione utente,
in modo da poter digitare il nome utente e la password,
e accedere e disconnettersi.
Pertanto, quando abbiamo creato questo modello cliente in base alla classe base del modello utente,
il modello cliente supporterà anche le
operazioni di accesso e disconnessione nell'utilizzo di questo modello cliente.
Quindi, possiamo accedere all'utente e disconnettere l'utente e così via.
Quindi, l'autenticazione utente arriva automaticamente per il diritto.
Quindi, per creare il modello cliente, al prompt,
digitare modello lb e per il nome del modello,
digiteremo Cliente.
E il DataSource, lo sceglierò come MongoDB.
E poi quando chiede di selezionare la classe base del modello,
invece di utilizzare il PersistedModel,
ci sposteremo verso il basso,
e quindi selezionare l'utente come classe base.
Quindi, in questo modo, deriverà tutte le loro proprietà
della classe utente di base già incorporata in Loopback.
E poi esporremo questo con l'API REST
e il MT plurale personalizzato.
E poi questo sarebbe nella cartella comune.
E per questo, le tre proprietà che aggiungeremo sono,
nome, che avremmo la stringa tipi.
E questo non è obbligatorio o non ha un valore predefinito.
E poi, cognome di nuovo come stringa di tipo,
non obbligatorio, e nessun valore predefinito.
E poi immagine della stringa di tipo,
non richiesta e nessun valore predefinito.
Quindi, si vede che la classe cliente stessa
porta proprietà aggiuntive oltre alla classe utente.
la classe utente supporta già il nome utente,
l'e-mail e le informazioni relative alla password.
Quindi, la classe cliente,
dal momento che la sottoclasse è la classe base,
otterremo il nome utente e l'e-mail automaticamente dalla classe utente.
E ora, quando vai al file model-config.jason,
vedrai che il modello Customer è già stato aggiunto lì.
E poi nei modelli comuni,
vedrai ora il file customer.json aggiunto lì
con queste tre proprietà aggiuntive che abbiamo aggiunto al modello cliente.
Ma nota, che specifica la base come classe utente per il modello cliente qui.
Quindi, è così che Loopback ti consente di prendere
una classe del modello di base e quindi sottoclasse quella nella classe del modello.
Quindi, vedrai come Loopback ci consente di supportare automaticamente l'autenticazione utente utilizzando
la classe utente e quindi ci permette di definire anche sottoclasse aggiuntiva di quello,
che memorizzerà ulteriori informazioni relative alla classe di base utente.
Successivamente, imposteremo il controllo degli
accessi per i vari modelli che abbiamo già impostato nel nostro server Loopback.
Quindi, per impostare il controllo di accesso
o gli elenchi di controllo di accesso in Lookback.
Loopback utilizza questi elenchi di controllo di accesso come un modo per specificare il tipo di
operazioni che possono essere eseguite
sui diversi endpoint API REST sono corrispondenti con i diversi modelli.
Quindi, per farlo, digiteremo al prompt lb acl,
ACL sta per Access Control List.
E poi, quando questo si esaurisce, diremo, a
quale modello vogliamo applicare questa lista di controllo di accesso.
E poi diremo, tutti i modelli esistenti.
E diremo, Tutte le metriche e le proprietà.
E diremo,
Tutti i tipi di operazioni.
E poi, diremo, Tutti gli utenti.
E poi diremo, negare esplicitamente l'accesso.
Quindi, stiamo prima chiudendo tutti i modelli per tutto,
poi ci apriremo lentamente,
indipendentemente dalle operazioni che possono essere eseguite da utenti diversi.
Quindi, primo passo, abbiamo chiuso
tutti i tipi di operazioni su tutti i modelli che abbiamo attualmente.
Quindi, inizieremo lentamente ad aprire ogni operazione, passo dopo passo.
Ora, il passo successivo,
quello che faremo è di nuovo impostare la prossima lista di controllo di accesso.
Nella seconda lista di controllo di accesso, diremo,
per tutti i modelli esistenti e diremo,
Tutte le metriche e le proprietà.
E poi, diremo, solo accesso in lettura.
Significato, quando l'utente può eseguire le operazioni GET su queste porte finali.
E queste operazioni GET possono essere eseguite da tutti gli utenti.
Quindi, gli utenti possono recuperare informazioni.
E concederemo esplicitamente l'accesso per questo.
Quindi, il che significa che le operazioni GET sono consentite sul nodo endpoint API REST.
Innanzitutto, abbiamo chiuso tutto,
quindi abbiamo aperto solo le operazioni GET per gli utenti.
Ora, infine, andranno a ciascuno dei modelli,
quindi chiuderanno e consentiranno di
eseguire determinate operazioni solo da determinati tipi di utenti.
Quindi, per farlo,
il prossimo ACL che imposteremo è per un modello specifico.
Quindi prepareremo questo per i piatti.
E diremo, Un singolo metodo.
E poi il nome del metodo è, crea.
Quindi, il che significa che la creazione di questi sarà consentita solo da.
Quindi, ancora una volta, quando si dice selezionare il ruolo,
quindi per il ruolo, diremo, altro.
E poi il nome del ruolo sarebbe admin.
Quindi, quello che stiamo facendo con questa operazione è che,
stiamo dicendo che solo un utente amministratore può creare nuovi piatti o aggiornare piatti esistenti.
Quindi, questo è un po 'vicino, le operazioni rimanenti.
Quindi, facciamo la stessa cosa per i leader.
E un singolo metodo e poi,
il creare e diremo,
solo l'amministratore può farlo.
E poi finalmente, anche per le promozioni.
Per le promozioni.
Il metodo singolo, il metodo create, sarà consentito
solo dagli utenti che hanno il ruolo designato come amministratore.
Vedremo come creeremo utenti con un ruolo specifico nel passaggio successivo.
Concedere esplicitamente l'accesso.
Ora si noti che non ho chiuso i clienti per le operazioni di creazione.
Se chiudo i clienti,
nessuno potrà registrarsi nel sistema.
Quindi, e' per questo che lascio aperto.
Perché, il cliente dovrebbe essere in grado di registrarsi nel sistema.
Quindi, puoi registrarti per nuovi account sul sistema.
Account utente sul sistema.
Quindi, questo sarà lasciato aperto alle persone.
Quindi, per consentire che per i clienti, diremo, clienti,
Un unico metodo, creare tutti gli utenti.
Pertanto, i clienti possono essere creati da tutti gli utenti perché ciò
consentirà alle persone di accedere al proprio account.
Infine, vedremo come possiamo configurare il nostro server per avviare
con un singolo utente amministratore automatico configurato nel nostro server Loopback.
Quindi, per farlo,
nel nostro server Loopback,
nella cartella server abbiamo questa sottocartella di avvio qui.
Qualunque sia il codice che abbiamo inserito nella sottocartella di avvio,
verrà eseguito all'avvio del nostro server LoopBack.
Quindi, qui, vedrai che abbiamo già questo authentication.js,
che è già impostato,
un Loopback che imposterà l'autenticazione utente per noi.
E poi abbiamo il root.js che imposterà
alcune informazioni aggiuntive per il nostro server RAM Loopback.
E possiamo aggiungere altri file qui.
Quindi, ho intenzione di andare lì nella cartella di avvio,
e quindi aggiungere questo file chiamato, script.js.
E in questo script.js,
ho intenzione di impostare il codice per creare un utente amministratore per impostazione predefinita.
Quindi, nel script.js,
che non sarà altro che un modulo NPM basato su file, quindi,
ci avvieremo dicendo,
module.exports = function (app).
L' app è l'app Loopback,
che verrà fornita come parametro per questa funzione per noi.
E così, possiamo farne uso all'interno del nostro codice qui.
Quindi, qui dentro, per prima cosa imposteremo un utente amministratore.
Quindi, per fare questo, diremo,
var Cliente = app.models.Customer.
Quindi, questo ci dà accesso al modello cliente.
Allora diremo, clienti.Findone.
Quindi, prima controlleremo per vedere se un utente con
il nome utente come amministratore è già configurato nel sistema o meno.
In caso contrario, creerò un utente amministratore.
E questo mi fornisce una funzione di callback con due parametri, err e utenti.
E all'interno di questo- Quindi cercheremo prima di
vedere se un utente con il loro nome admin esiste già.
Se l'utente non esiste
, creeremo l'utente.
Quindi, per creare l'utente,
diremo qui, se non gli utenti.
Quindi, se gli utenti non sono nulli o se l'utente dice null,
ciò significa che non esiste un utente amministratore, quindi ho bisogno di creare un utente amministratore qui.
Quindi, in questo caso, diremo, cliente.create.
E questa creazione richiede una serie di oggetti, se vuoi.
E questa matrice di oggetti ci permetterà di specificare quali account utente vogliamo creare.
Quindi il primo account utente che voglio creare o
l'unico account utente che voglio creare è «Amministratore».
Quindi questo sarà l'amministratore predefinito per
il mio server di loopback e quindi posso configurare l'e-mail.
Quindi ricorda che il modello utente supporta queste proprietà,
confusion.net e quindi password
che configurerò come password.
È anche possibile fornire insieme a questo,
il nome e il cognome,
se si desidera, per l'utente amministratore.
Ma ho intenzione di lasciarlo come tale,
come vuoto perché quelli non sono richiesti per l'utente admin.
Quindi lo lascio lì.
Quindi questo comando finirà per creare un nuovo cliente con il nome 'Admin'.
Quindi, se questo utente o il nome «Admin» non esiste,
allora stiamo andando a crearne uno.
E poi qui abbiamo la funzione di callback.
Quindi sbagliare gli utenti.
Ora dirò,
se sbagliamo, non sappiamo cosa sta cercando di fare, quindi semplicemente lanciamo l'errore.
Ma normalmente non ci aspettiamo che questo accada.
Quindi ora, come si designa questo utente come utente amministrativo?
Quindi in questo momento, quando mi iscrivo qui,
sto solo registrando un utente normale qui,
ma vogliamo dare un ruolo speciale a questo utente.
In questo modo loopback supporta un modo di specificare i ruoli per gli utenti.
Quindi, per specificare un ruolo,
ci var ruolo = app.models.Role.
Quindi questo mi permetterà di creare un ruolo,
un nuovo ruolo chiama admin qui.
Quindi possiamo assegnare diversi droni a utenti diversi, se vuoi.
E insieme a questo,
ho anche bisogno di creare un RoleMapapping qui.
Quindi diremo, App.Models.RoleMapping.
E se succede che il database contiene già un
RoleMapping che esiste già,
allora distruggerò tutti quelli quando avvio il mio server.
E poi fammi provare
a trovare per vedere se un ruolo con
quel nome admin
esiste già nel sistema.
Ok.
E in questo richiede,
come ci si aspetterebbe,
una funzione di callback e dentro qui diremo, ruolo.findone.
Quindi se esiste già un ruolo con il nome admin,
non ho bisogno di crearne uno.
Altrimenti, se ciò non esiste,
allora ho bisogno di creare il ruolo.
Quindi diremo, ruolo.Creare.
Quindi creeremo il ruolo di amministratore qui.
E poi questo ci porta ai parametri err,
ruolo qui, nella funzione di callback.
Ora di nuovo, qui per gestire l'errore,
copieremo questo 'if err' e poi incollarlo lì.
Allo stesso modo anche qui, se si verifica l'errore,
allora ho bisogno di gestirlo.
Quindi 'se erra' allora 'getta la erra'.
Altrimenti, abbiamo creato il ruolo.
Quindi ora ho bisogno di mappare questo ruolo a questo particolare utente che ho appena creato.
Questo utente che ho appena creato qui.
Questo utente. Voglio dare a questo utente quel ruolo di amministratore.
Quindi, dal momento che ho creato questo ruolo dal nome admin,
quindi diremo, role.principals.create.
Quindi questo è il modo in cui si crea una mappatura tra il ruolo e un particolare utente qui.
Quindi diremo, ruolo.principals.create.
Quindi questa è la sintassi lì.
Diciamo, PrincipalType: RoleMapping.User
qui e prenderai
un id principale qui che è gli utenti.
Ora a cosa si riferisce questo utente?
Questo utenti si riferisce a questo che è appena entrato.
Così, quando abbiamo creato questi utenti,
allora il cliente deve creare un ritorno di successo a noi qui.
Quindi questo è quello che userò qui.
Diciamo, gli utenti [0].
Quindi questo sarebbe un array di utenti che sono stati creati e contengono solo uno di essi.
Ecco perché sto dicendo utente [0].
E poi assegneremo l'ID di quell'utente qui.
Quindi questo è il modo in cui creeremo un RoleMapping tra il ruolo che abbiamo appena creato
, questo ruolo, e quindi mapparlo al cliente che abbiamo appena creato.
Ora questo ci porta anche ai parametri, la funzione di callback.
E in questa funzione di callback diremo semplicemente,
se (err) lancia (err).
Altrimenti non siamo davvero interessati a sapere cos'altro è successo lì.
Questo è tutto. Allora, ecco come.
Quindi, se il ruolo denominato admin non esiste,
creeremo quel ruolo.
Se non- Quindi questa è la
parte 'else' in cui avrò ancora bisogno di fare questa mappatura.
Quindi fammi copiare quel codice e poi lo farò esattamente qui.
Quindi role.principals.create e quindi mappare questo per l'utente lì.
Quindi, se il ruolo di amministratore esiste già,
tutto ciò che devono fare è fare la mappatura.
Quindi questo sarà memorizzato nel modello RoleMapping nel nostro database. Questo è tutto.
Quindi questo pezzo di codice che inseriamo nel file script.js cercherà prima di
scoprire se esiste un utente amministratore e quell'utente è identificato dal nome admin.
In caso contrario, l'utente verrà creato e quindi creerà il ruolo per l'utente.
Verrà creato un ruolo denominato admin.
Se quel ruolo esiste,
allora lo useremo.
Altrimenti creeremo il ruolo.
E poi creeremo questa mappatura tra il ruolo e l'utente.
Quindi loopback ci permette di fare il RoleMapping.
Quindi dire che questo utente non è a questo ruolo.
Quindi questa mappatura viene eseguita utilizzando questa istruzione.
Questo completa la configurazione dei nostri server.
In modo che un utente amministratore venga creato e che l'utente amministratore
otterrà automaticamente il ruolo dell'amministratore come configurato qui.
Questo è tutto. Salviamo le modifiche a script.js.
E ora i nostri server di loopback dovrebbero essere pronti.
Quindi ora andremo e inizieremo il nostro server di ritorno e poi controlleremo cosa possiamo fare con questo.
Andando ai terminali,
iniziamo il server di loopback.
Quindi diremo, npm start e poi il nostro server dovrebbe essere attivo e funzionante.
Andiamo a Explorer e poi sfogliare le informazioni lì.
E questo server di loopback si sarà
connesso automaticamente al mio MongoDP perché ho impostato la connessione.
Andando al mio browser,
fammi ricaricare questo.
E quando ricarico questo,
ora vedrai che abbiamo un nuovo cliente che è stato creato qui.
L' utente esisteva già in precedenza.
I piatti, i leader e le promozioni sono tutti lì.
Eseguiamo un get sui piatti.
Ora che questo è collegato alla bocca MongoDB,
il mio MongoDB ha già alcuni piatti lì dentro.
Se il tuo MongoDB è vuoto,
puoi pubblicare alcuni piatti usando il post qui.
Quindi proviamolo.
Quando faccio un'operazione get sui piatti barra,
vedrete che nel corpo di risposta-
Tutti i piatti che esistono nel mio database sono stati recuperati.
Allo stesso modo, posso fare un GET sulle
promozioni e dovrei vedere la promozione che esiste già nel mio database lì.
Quindi, puoi vedere che la promozione esiste già lì.
Quindi, questo ci mostra come possiamo recuperare informazioni.
Ora, proviamo a postare un nuovo piatto.
Quindi, per pubblicare un nuovo piatto,
andiamo al POST qui.
Fammi copiare questo.
Ovviamente,
in questo momento, perché dal momento che non sono un loggato,
non mi sarà permesso di postare il piatto così,
ma dimostrerò che a voi sono solo copiare e incollare queste informazioni qui,
e cercheremo di postare quel piatto,
e poi quando provo a postare il piatto, il
mio server risponde immediatamente con questo errore dicendo, AUTORIZATION_REQUISED.
Non sei autorizzato a eseguire questa operazione.
Quindi, ecco perché non sei autorizzato a fare questa operazione.
Ora, come ti autorizzi?
Quindi, per autorizzarti,
ora ricorda che abbiamo già creato un utente con il nome admin,
e questo utente admin esiste già come cliente qui.
Quindi, andando negli endpoint dell'API REST del cliente,
se scorri verso il
basso, qui sotto, vedrai l'accesso di questo cliente.
Quindi, quando fai un POST sul login del cliente.
Quindi, per il login del cliente,
scorri qui e poi qui chiede le credenziali.
Quindi, nelle credenziali,
possiamo digitare il nome utente tra virgolette doppie, e diremo,
Admin, e poi password,
diremo, password, e poi pubblicheremo questo.
E poi quando lo
pubblicherai, noterai che nella risposta,
LoopBack mi invierà indietro queste informazioni.
Ora, all'interno di queste informazioni,
questo particolare id che invia indietro è l'accesToken per il mio server LoopBack.
Quindi, posso semplicemente copiare questo AccesStoken qui,
e poi proprio in alto qui,
puoi vedere che questo è Token Not Set, qui.
Dice Token Not Set.
E qui puoi digitare questo accesToken,
e poi dire, Imposta token di accesso.
E poi il tuo AccesStoken verrà impostato,
e quindi tutte le operazioni successive che esegui porteranno automaticamente
questo AccesToken nell'intestazione del mio messaggio di richiesta.
Quindi, in questo modo, ora il mio amministratore sarà autorizzato a fare post di articoli lì.
Quindi, ora che ho effettuato l'accesso come amministratore,
lasciami andare alle promozioni,
e poi pubblicherò una promozione lì,
e ti mostrerò che posso effettivamente pubblicare promozioni.
Quindi, andiamo a un POST,
e poi ci limiteremo a copiare questo, e poi nei dati,
e poi per il nome diremo, Promozione test,
e immagine lo lasceremo come tale, descrizione, Descrizione del test.
E posso postarlo lì,
e vedrai
che non dovrei includere questo id qui perché ho
lasciato che LoopBack assegni automaticamente l'id ad esso.
Lasciami pubblicare questo e poi vedresti che nel corpo della risposta,
la promozione del test è stata postata qui.
E ho appena notato che non ho incluso
la bandiera in primo piano per le mie promozioni e i miei leader.
Quindi, ho intenzione di entrare e includere la bandiera in primo piano come
una delle parti delle mie promozioni lì.
Quindi, ora quando faccio un GET per le promozioni,
vedrai che in quel messaggio di risposta,
vedrai la vecchia promozione che era già nel mio database
e poi la nuova promozione che ho appena pubblicato nel mio database già incluso qui.
Così, ho appena notato che ho bisogno di impostare il flag in primo piano,
vi mostrerò come farlo in un.
Quindi, questo tipo di dimostra a voi come è possibile accedere ed esplorare il vostro server LoopBack.
Permettetemi di distruggere questo token,
quindi rimuoveremo il token
e quindi
cliccheremo su di esso in modo che essenzialmente invii il token di accesso a una
stringa vuota e quindi il mio token non elaborerà più,
quindi ora il mio utente non è più connesso.
Permettetemi di creare un nuovo cliente.
Quindi, per creare un nuovo cliente dirò, clienti POST.
E poi mi limiterò a copiare questo da qui.
Mi creerò un nuovo account qui.
E così, qui,
rimuoverò il regno,
non ne ho bisogno, non ho bisogno dell'id.
Quindi, per il nome
e l'EmailVerified dovrebbero essere impostati automaticamente dal sistema.
Quindi, lasciami accedere come questo utente.
Quindi, sto solo andando a inviare il mio nome, cognome
e l'immagine attualmente,
mi limiterò a impostare una stringa vuota lì, nome utente ed e-mail.
E poi lo proveremo,
e poi ritorna dicendo,
Dettagli: 'password' non può essere vuota.
Quindi, noterai che qui,
dovrei anche includere insieme al nome utente, alla
password e poi, postiamo questo.
Quindi, quando lo pubblichi, ritorna con
il corpo di risposta che dice che ora fai parte del sistema.
Quindi, il tuo nome,
il tuo cognome e il tuo nome utente, il tuo ID email
e l'ID che LoopBack ti assegna vengono inviati a te.
Quindi, questo non è altro che l'id MongoDB come puoi vedere qui.
Quindi, ora che mi sono iscritto come cliente,
dovrei essere in grado di accedere come cliente,
in modo che andrò al login POST qui,
e poi qui invece dell'amministratore,
accederò come nuovo utente a cui ho effettuato l'accesso.
Quindi, poi faccio clic su per Provalo,
vedrai che ritorna con l'id,
quindi mi dà il token per questo utente amministratore qui.
Quindi, con questo abbiamo completato l'esame del server LoopBack che abbiamo appena creato.
E come ho appena detto,
ho notato che le promozioni e i leader non hanno bandiera caratteristica quindi,
ho intenzione di entrare nel codice.
Quindi, supponiamo di dimenticare qualcosa del genere,
allora puoi semplicemente entrare e modificare il codice Json se lo desideri.
Quindi, andrò nel mio codice,
andando al codice,
andrò prima in commons e poi andrò in dishes.json.
E poi nel dishes.json,
vedo questa proprietà in evidenza lì.
Ho intenzione di copiare questa proprietà in primo piano,
e poi andrò in leaders.json,
e poi incollerò quella proprietà caratteristica in un leaders.json,
e anche con promotions.json.
Ho dimenticato di includere questo quando ho creato quei modelli.
Avrei dovuto farlo quando stavo creando il modello stesso quindi,
se dimentichi qualcosa del genere,
allora questo è un altro modo per modificare il tuo modello
e quindi assicurarmi che il tuo modello sia impostato correttamente.
Quindi, questo è tutto.
Quindi, ora le mie promozioni e leader avranno anche la bandiera in primo piano.
Con questo, completiamo questo esercizio.
In questo esercizio, abbiamo visto come possiamo impostare
un nuovo modello estendendo una classe modello di base che è già in LoopBack.
Abbiamo anche visto come
è possibile impostare i controlli di accesso utilizzando gli elenchi di controllo di accesso supportati da LoopBack.
Con questo, completiamo questo esercizio.
Questo è un buon momento per voi di fare un ottenere coperto con
il messaggio LoopBack origini dati e controllo di accesso.