Questa è una grande domanda perché mostra come funziona il modello di sicurezza Meteor.
Non c'è alcun problema di sicurezza qui perché Meteor mai si fida del codice client.
In Meteor, solo il server decide a quali dati ha accesso ogni client (vedere Meteor.publish) e quali dati è consentito a ciascun client di modificare (vedere Meteor.allow). Quando un client si autentica sul server, il server memorizza l'ID dell'utente. Fino a quando il client si disconnette, fornisce quell'ID alle funzioni Meteor.publish
e Meteor.allow
sul server come userId
.
Meteor invia anche l'ID utente sul client, perché ovviamente si desidera modificare il modo in cui il client si comporta e cosa c'è sullo schermo in base a chi ha effettuato l'accesso. E come dici tu, non possiamo fermare un ladro client da modificare arbitrariamente qualsiasi codice JavaScript per modificare quello che pensa sia l'ID utente! Ma farlo non dà al client alcuna nuova autorizzazione, perché è ancora solo il codice server che prende le decisioni di sicurezza.
Si può provare questo utilizzando l'applicazione partiti sicuro:
- Fai un app partiti con
$ meteor create --example parties
- Creare un account utente e fare doppio clic sulla mappa per creare un partito. Seleziona la casella per renderla una festa privata.
- Aprire la console JavaScript e digitare
Meteor.userId()
per ottenere l'ID dell'utente.
- Disconnettersi. La festa sparirà dallo schermo perché il server non la pubblicherà su nessun altro utente.
- Ora, passare alla console e sovrascrivere
Meteor.userId()
con una nuova funzione che restituisce l'ID desiderato.
Quindi ora hai simulato il cliente per pensare che sia il tuo utente. Ma il server lo sa meglio. Non ci sarà ancora una parte sullo schermo e non è possibile aggiornare la raccolta delle parti per modificare le informazioni sulla festa.
In effetti, è completamente sicuro impostare l'ID utente del client su tutto ciò che si desidera! Puoi raggiungere direttamente il sistema degli account e chiamare lo Meteor.default_connection.setUserId("aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee");
. Provalo e vedrai che il pulsante di accesso nell'angolo in alto a destra diventa un'animazione. Questo perché il client sta chiamando Meteor.user()
per mostrare l'indirizzo email dell'utente che hai appena effettuato l'accesso. Ma dal momento che non hai effettuato l'accesso al server come tale utente, non pubblicherà alcuna informazione su quell'utente e avrai solo lo spinny.
Questo è un modello di sicurezza molto forte. Non devi preoccuparti di alcun codice client, anche se nella maggior parte delle app è dove vive la maggior parte del codice! Finché si scrivono metodi server sicuri, funzioni di pubblicazione e allow/deny rules, si è completamente bloccati, indipendentemente dal tentativo del client.
Il 'loginToken' rappresenta le" chiavi del regno "per l'account corrispondente (per la durata del token, 90 giorni per impostazione predefinita). Quindi salvaguardare il token è fondamentale, perché in caso di perdite, chiunque può autenticare una connessione DDP a quel server/account (vedere il pacchetto npm [ddp-login] (https://www.npmjs.org/package/ddp-login) , per esempio). – vsivsi
Quindi, in pratica, stai dicendo che se qualcuno ha accesso fisico al tuo computer per copiare il tuo ID di accesso e il token che * tutte le scommesse sono disattivate *. Cosa possiamo fare veramente su questo? Questo è altrettanto insicuro di qualcuno che copia le tue chiavi SSH se hanno il tuo computer, eppure SSH è considerato davvero sicuro ... Quindi, crittografa il tuo computer. :) – trusktr