Metodo Meteor vs. nega / consenti le regole

In Meteor, quando dovrei preferire un metodo su una regola di deny ?

Mi sembra che le regole di deny / deny debbano essere favorite, poiché il loro objective è più esplicito e si sa dove cercarle.

Tuttavia, nel libro Discover Meteor, si impedisce di inserire duplicati (“duplicato” essendo definito come aggiunta di un documento la cui proprietà url è già definita in qualche altro documento della stessa collezione) si dice che debba essere definito attraverso un metodo (e lasciato come un esercizio per il lettore, capitolo 8.3).

Penso di essere in grado di implementare questo controllo in un modo che trovo molto più chiaro:

 Posts.deny({ update: function(userId, post, fieldNames, modifier) { return Posts.findOne({ url: modifier.$set.url, _id: { $ne: post._id } }); } }); 

(NB se si conosce l’esempio, sì, ho volontariamente omesso “solo un sottoinsieme degli attributi è stato modificato”, il controllo dalla domanda è più specifico).

Capisco che ci sono altri operatori di aggiornamento di $set in Mongo, ma sembrano digitati e non ho voglia di lasciare un buco di sicurezza aperto.

Quindi: ci sono dei difetti nella mia regola di deny ? Indipendentemente, dovrei favorire un metodo? Cosa potrei guadagnare da questo? Cosa dovrei perdere?

Normalmente cerco di evitare risposte soggettive, ma questo è un dibattito davvero importante. Prima di tutto raccomanderei di leggere Metodi Meteor vs Operazioni lato client dal blog Discover Meteor. Nota che in Edthena usiamo esclusivamente metodi per ragioni che dovrebbero diventare evidenti.

metodi

professionista

  • I metodi possono applicare correttamente lo schema e le regole di convalida di complessità arbitraria senza la necessità di una libreria esterna. Nota a margine: il controllo è uno strumento eccellente per convalidare la struttura dei tuoi input.

  • Ogni metodo è una singola fonte di verità nella tua applicazione. Se crei un metodo “posts.insert”, puoi facilmente verificare che sia l’unico modo nella tua app di inserire post.

contro

  • I metodi richiedono uno stile imperativo e tendono ad essere prolissi in relazione al numero di convalide richieste per un’operazione.

Operazioni sul lato client

professionista

  • allow / deny ha un semplice stile dichiarativo.

contro

  • Convalidare schema e permessi su un’operazione di update è infinitamente difficile. Se è necessario applicare uno schema, è necessario utilizzare una libreria esterna come collection2 . Solo questa ragione dovrebbe darti una pausa.

  • Le modifiche possono essere distribuite su tutta la tua applicazione. Pertanto, potrebbe essere difficile identificare il motivo per cui è avvenuta un’operazione di database specifica.


Sommario

A mio parere, allow / deny è esteticamente più piacevole, tuttavia la sua debolezza fondamentale è nell’attribuire le autorizzazioni (in particolare sugli aggiornamenti). Consiglierei le operazioni lato client nei casi in cui:

  • La tua base di codice è relativamente piccola, quindi è facile usare grep per tutte le istanze in cui si verifica un particolare modificatore.

  • Non hai molti sviluppatori, quindi non è necessario che tutti concordino che esiste un solo modo per inserirli nella raccolta X.

  • Hai regole di authorization semplici, ad esempio solo il proprietario di un documento può modificarne qualsiasi aspetto.

Secondo me, utilizzare le operazioni lato client è una scelta ragionevole quando si crea un MVP , ma passerei ai metodi per tutte le altre situazioni.


aggiornamento 22/2/15

Sashko Stubailo ha creato una proposta per sostituire consentire / negare con metodi di inserimento / aggiornamento / rimozione .

aggiornamento 6/1/16

La meteora prende la posizione che allow/deny dovrebbe sempre essere evitata .