In che modo breeze.js gestisce la sicurezza ed evita di esporre la logica aziendale

Question

Stiamo considerando breeze js per la creazione di applicazioni aziendali.

L'aspetto fantastico di brezza è che siamo in grado di eseguire query direttamente dal browser client. Ciò consente di costruire query dinamiche basate sull'input dell'utente senza caricare dati non necessari. Ho scoperto che utilizzando Breeze possiamo creare una logica di business che riduce i dati che viaggiano/trasferiscono di 1/10 o anche di più quando si utilizza una strategia di caricamento lenta. utilizzando query come these

Urrina brezza !!!

Ma per quanto riguarda la sicurezza di Business Logic, Ad esempio, potremmo avere un repository in cui possiamo nascondere, nascondere e oscurare la nostra logica aziendale; quindi utilizzare i controller MVC Web API per effettuare solo chiamate a tali classi C# del repository. quindi JavaScript di Breeze comunica con il controller WebAPi e il controller WebApi comunica con il repository C#. I controllori saranno sempre mantenuti molto semplici e facili da leggere, ma il repository potrebbe finire per avere un sacco di logica di business per l'azienda che utilizza l'applicazione. Quindi, se un hacker utilizza, ad esempio, la console degli sviluppatori di Google Chrome per ispezionare il codice JavaScript, vedrà solo cose come GetCustomers(), GetProductsForThisId (54). Non ci sono molte informazioni che possono essere viste (o rubate) lì. Perché il 90% di Business Logic risiede sul repository C# sul server.

In che modo breeze.js lo gestisce?

Se iniziamo a spostare le query e la logica aziendale "dal C# del controller al brezza JavaScript", dobbiamo considerare che il nostro sistema è basato sull'iscrizione. Penso che quante più domande vengono esposte al client in JavaScript, tanto più vulnerabile diventa il nostro software, e più diciamo agli hacker come hackerare il nostro sito Web e possibilmente rubare informazioni.

Answer 1

La sicurezza è una preoccupazione vitale. È saggio pensare attentamente ai dati e alla logica esposti sul client. Come possiamo affinare questi sentimenti in una domanda concreta adatta per una risposta SO?

Niente su Breeze dovrebbe causare l'esposizione della logica di business al client JavaScript. È possibile (e dovrebbe) bloccare tale logica in modo sicuro all'interno dei repository e/o dei metodi del controller.

Ma faccio fatica a capire come cliente si interroga sono i tipi di logica di business che hanno bisogno di protezione. Dov'è il pericolo in una query per un cliente il cui nome inizia con "A"?

Si può giustamente preoccuparsi di una richiesta per i clienti con un patrimonio netto> $ 100.000. Ma l'errore non è nella query. La colpa sarebbe di esporre tali informazioni cliente di utenti non autorizzati con qualsiasi mezzo, a mezzo di una Breeze dove clausola aggiuntiva al una query o una chiamata a un servizio denominato GetCustomers().

Il luogo di bloccare l'accesso non autorizzato ai clienti è sul server e si può fare la stessa facilità all'interno di un metodo azione del controller Breeze ritorno IQueryable, come si può nel vostro GetCustomer) metodo (. In entrambi i casi l'onere ricade su di te per imporre i vincoli di sicurezza necessari sul tuo controller e nei metodi che esponi.

Si scrive il controller. Scrivi i repository. Hai accesso alle autorizzazioni dell'utente.Hai il completo controllo con una capacità senza compromessi di esporre quanto più o meno desideri.

FWIW, il vostro Breeze EntityManager può chiamare metodi di servizio che non restituiscono IQueryable<Customer>. Può chiamare metodi di controllo Web Api come IEnumerable<Customer> GetCustomers() o Product GetProductForId(int id). A mio avviso, perderai la flessibilità delle funzionalità di query di Breeze senza ottenere alcuna sicurezza. Ma questa è solo la mia opinione. Breeze supporterà la tua scelta, qualunque essa sia.

Sarei felice di provare a rispondere a una domanda di "come fare" più specifica.

Answer 2

vorrebbe aggiungere che è possibile limitare gli utenti che non sono autorizzati da quering utilizzando gli attributi in webapi se si ottiene il codice 401 indietro dal server solo popup una schermata di accesso e ripetere il lavoro necessario dopo che l'utente è loggato

in modo che un utente può cercare di ottenere dati relativi a un ordine, ma non lo otterrà a meno che non sia autorizzato a farlo

Answer 3

è possibile per un sacco di cose usando breeze.js Prima di tutto controllare il mio risposta per sicurezza qui

How to handle authorization with Breeze JS?

Anche se breeze.js può essere utilizzato come un normale ORM sul client (che può essere estremamente utile a volte), è necessario mantenere la logica aziendale nei controller API Web ed esporre solo le informazioni necessarie utilizzando le query OData. Se è necessaria una logica di manipolazione dei dati, è necessario farlo sul server utilizzando un metodo specifico.

Solo la logica dell'interfaccia utente deve essere presente sul client, considerare anche che ci sono diverse implicazioni sulle prestazioni se si inizia ad eseguire più query direttamente dal client. Espandi il grafico dell'entità per caricare più risultati o utilizza metodi più specializzati che restituiscono l'oggetto. Breeze introspetterà i risultati e consumerà le entità felicemente senza implicazioni.