C'è qualche motivo per non passare direttamente da Javascript lato client a un database?

Possibile duplicato:
scrittura di applicazioni Web "server less"

Quindi, supponiamo che costruirò un clone di Stack Exchange e deciderò di utilizzare qualcosa come CouchDB come archivio back-end. Se utilizzo l'autenticazione integrata e l'autorizzazione a livello di database, c'è qualche motivo per non consentire al Javascript lato client di scrivere direttamente sul server CouchDB pubblicamente disponibile? Dato che si tratta fondamentalmente di un'applicazione CRUD e la logica aziendale consiste in "Solo l'autore può modificare il proprio post" Non vedo molto il bisogno di avere un livello tra il lato client e il database. Vorrei semplicemente utilizzare la convalida sul lato CouchDB per assicurarmi che qualcuno non stia inserendo i dati spazzatura e assicurarmi che le autorizzazioni siano impostate correttamente in modo che gli utenti possano solo leggere i propri dati _user. Il rendering verrebbe eseguito sul lato client da qualcosa come AngularJS. In sostanza potresti semplicemente avere un server CouchDB e un mucchio di pagine "statiche" e sei a posto. Non avresti bisogno di alcun tipo di elaborazione sul lato server, solo qualcosa che potrebbe servire le pagine HTML.

L'apertura del mio database al mondo sembra sbagliata, ma in questo scenario non riesco a pensare al motivo fino a quando le autorizzazioni sono impostate correttamente. Va contro il mio istinto di sviluppatore web, ma non riesco a pensare a una buona ragione. Quindi, perché questa è una cattiva idea?

EDIT: Sembra che ci sia una discussione simile qui: Scrivere applicazioni Web "server less"

EDIT: Discussione fantastica finora, e apprezzo il feedback di tutti! Sento che dovrei aggiungere alcune ipotesi generiche invece di chiamare specificamente CouchDB e AngularJS. Quindi supponiamo che:

• Il database può autenticare gli utenti direttamente dal suo archivio nascosto
• Tutte le comunicazioni del database avverrebbero tramite SSL
• La convalida dei dati può (ma forse non dovrebbe?) Essere gestita dal database
• L'unica autorizzazione che ci interessa oltre alle funzioni di amministrazione è che a qualcuno è permesso solo modificare il proprio post
• Stiamo perfettamente bene con chiunque sia in grado di leggere tutti i dati (TRANNE i record degli utenti che possono contenere hash delle password)
• Le funzioni amministrative sarebbero limitate dall'autorizzazione del database
• Nessuno può aggiungersi a un ruolo di amministratore
• Il database è relativamente facile da ridimensionare
• C'è poca o nessuna vera logica aziendale; questa è un'app CRUD di base

Fare come suggerisci crea un accoppiamento stretto tra la tua lingua lato client e il tuo database.

Questo può andare bene - c'è meno codice da scrivere e mantenere, e in teoria il debug potrebbe / dovrebbe andare un po 'più veloce.

D'altra parte, rende altri aspetti più difficili. Se / quando dovessi cambiare una di queste tecnologie, avrai un momento più difficile a causa del loro stretto accoppiamento.

Proteggersi dagli attacchi sarà (abbastanza) un po 'più difficile. Supponete che il client presenterà sempre richieste ben formattate al database. Ciò presume che nessuno potrà mai hackerare il codice lato client per inserire dichiarazioni dannose. In altre parole, "prenderanno in prestito" i meccanismi di autenticazione e sostituiranno il normale codice client con il loro.

Non lo consiglierei, e molti ti direbbero con veemenza di non farlo. Ma si può fare.

Probabilmente non è una grande idea. E la prima e più forte ragione che posso dare è che un server di database non è progettato per essere un web server pubblico. Al contrario, la saggezza convenzionale dice che dovresti nascondere il tuo database dietro un firewall.

Se hai bisogno di prove a sostegno, ci sono molte preoccupazioni - non tutte insormontabili, ma molte su cui riflettere. In nessun ordine particolare, eccone alcuni:

• Non può eseguire la sanificazione delle query, perché le stai inviando direttamente.
• Le autorizzazioni del database tendono a funzionare in modo diverso rispetto alle autorizzazioni del server Web e dell'applicazione. I server Web e i framework applicativi non ti avviano con nulla e devi creare ed esporre esplicitamente risorse, endpoint e azioni individuali. I database, d'altra parte, ti chiedono di concedere ruoli ad alto livello.
• Probabilmente non è ben ottimizzato per sostenere il carico di lavoro di un web server; non puoi beneficiare del pool di connessioni.
• I server Web più popolari sono stati suddivisi in molti . E hanno ricevuto molte patch di sicurezza. Il tuo DBMS è stato sostanzialmente progettato per nascondersi dietro un firewall, quindi probabilmente non è stato testato nemmeno da una frazione dell'uno per cento delle potenziali minacce che dovrà affrontare sul web pubblico.
• È necessario utilizzare il linguaggio di query del database per proteggere i dati privati. A seconda del tuo DBMS, questo può essere impegnativo.
• È necessario utilizzare il linguaggio di query del database per filtrare set di dati di grandi dimensioni, cosa che si potrebbe tentare di fare comunque; ma qualcosa che può diventare oneroso per regole aziendali più complicate.
• Supporto limitato o assente per librerie di terze parti.
• Supporto della comunità molto limitato (potenzialmente zero) per molti dei problemi che incontrerai.

... E sono sicuro che ci sono altre preoccupazioni. E sono sicuro che c'è una soluzione per la maggior parte - se non tutte queste preoccupazioni. Ma c'è un elenco per iniziare!

Il miglior singolo motivo che posso immaginare è: perché questo metodo non è direttamente supportato o raccomandato da nessuna delle parti coinvolte.

I fornitori di browser, gli standard EcmaScript, gli sviluppatori di sistemi di database, le società di apparecchiature di rete, gli architetti di hosting / infrastruttura e gli specialisti della sicurezza non supportano attivamente (o forse nemmeno prendono in considerazione) il caso d'uso proposto. Questo è un problema, perché il metodo proposto richiede che tutte queste entità - e altre ancora - funzionino correttamente per l'applicazione, anche se nessuno dei sistemi coinvolti è stato progettato per supportare questo.

Non sto dicendo che non è possibile. Sto solo dicendo che è meno come "reinventare la ruota" e più come reinventare l'interazione client-server basata su browser.

Nel migliore dei casi, farai un sacco di lavoro anche per far funzionare i sistemi al livello più elementare possibile. I database popolari moderni non sono RESTful o costruiti per funzionare su HTTP, quindi costruirai i tuoi driver client basati su WebSocket (presumo).

Anche se riuscirai a far funzionare tutto tecnicamente, rinuncerai a molte delle funzionalità più potenti delle architetture moderne. Non avrai alcuna difesa in profondità: tutti possono facilmente connettersi direttamente al bersaglio principale della maggior parte dei tentativi di hacking del sito Web. Ma lo scenario che proponi è molto, molto peggio di così.

Il modello proposto non sta solo esponendo il server, ma sta esponendo stringhe di connessione valide. Gli aggressori non possono semplicemente eseguire il ping del server: possono accedere attivamente e inviare comandi. Anche se puoi limitare l'accesso ai dati, non sono a conoscenza di strumenti sufficienti nei sistemi DBMS per proteggere dagli scenari Denial of Service e dai loro simili. Quando si lavora in versioni avanzate di SQL, come TSQL, è spesso banalmente facile produrre bombe che funzionano efficacemente all'infinito (alcuni join illimitati per produrre un prodotto cartesiano e si avrà un SELECT che funzionerà per sempre, facendo un lavoro pesante) . Immagino che dovresti disabilitare la maggior parte delle funzionalità di SQL, anche eliminando le query SELECT di base con JOIN e forse consentire solo la chiamata di stored procedure? Non so nemmeno se puoi farlo, non mi è mai stato chiesto di provare. Non

La scalabilità del database tende inoltre a essere uno dei problemi più difficili nel lavorare su larga scala, mentre il ridimensionamento di più server HTTP - specialmente con pagine statiche o memorizzate nella cache - è una delle parti più semplici. La tua proposta fa sì che il database faccia più lavoro essendo responsabile fondamentalmente del 100% dell'attività sul lato server. Questo è un difetto assassino da solo. Quello che guadagni spostando il lavoro sul client lo perdi spostando più lavoro nel database.

Infine, vorrei solo sottolineare che il cuore di ciò che proponi non è nuovo, ma in realtà risale a decenni fa. Questo modello è chiamato modello "database fat", che sostanzialmente ha spostato la maggior parte della logica lato server nel database proprio come si propone. Ci sono molte ragioni per cui il modello è andato di lato su Internet di massa, e probabilmente sarebbe istruttivo esaminare di più quella storia da soli. Si noti inoltre che anche in quel momento si prendeva in considerazione la possibilità di avere utenti completamente non fidati in grado di accedere al sistema ed eseguire comandi, poiché l'accesso sarebbe comunque controllato per selezionare utenti interni (noti) che non avrebbero dovuto attaccare costantemente il sistema.

Il fatto è che avrai ancora bisogno di un server HTTP per servire i file, dato che i sistemi di database non lo fanno. Allo stesso tempo, tutto ciò che proponi può essere ottenuto utilizzando un modello di server sottile (come con Nodejs) per esporre un'interfaccia RESTful nel tuo database. Questo è popolare per un motivo: funziona, mantiene il database nascosto dietro i livelli di protezione, è estremamente scalabile e tuttavia ti consente di costruire il tuo database come spesso o sottile come ti interessa.

Dato che si tratta fondamentalmente di un'applicazione CRUD e la logica aziendale consiste in "Solo l'autore può modificare il proprio post" Non vedo molto il bisogno di avere un livello tra il lato client e il database. Vorrei semplicemente utilizzare la convalida sul lato CouchDB per assicurarmi che qualcuno non stia inserendo i dati spazzatura e assicurarmi che le autorizzazioni siano impostate correttamente in modo che gli utenti possano solo leggere i propri dati _user.

Bene, mettere l' autorizzazione (i problemi di sicurezza) e la convalida della logica lontano dal database fornisce separazione dei problemi nel sistema software. Pertanto, è possibile testare, mantenere, ridimensionare e riutilizzare i blocchi di codice logici con meno rischi di frenare la funzionalità nel sistema.

Fornire la capacità per l'input del client di comunicare direttamente con il database ha un grande potenziale per rovinare i dati .

Ciò significa anche che evitare / rimuovere l' accoppiamento stretto rende il sistema software più gestibile e SOLIDO.

Consentire all'utente di interagire direttamente con il database mi sembra davvero pericoloso.

Il meccanismo di autenticazione di CouchDB è davvero così sofisticato che puoi isolare l'accesso in lettura e scrittura di un utente solo ai dati che dovrebbe leggere e scrivere (stiamo parlando di accesso per documento, forse anche per campo di documento privilegi qui)? Che dire dei dati "comuni" che sono condivisi da più utenti? Questo non esiste affatto nella progettazione dell'applicazione?

Vuoi davvero che l'utente sia in grado di modificare i suoi dati in QUALSIASI modo? Che dire delle iniezioni di XSS, per esempio? Non sarebbe meglio avere un livello server per filtrarli prima che entrino nel database?

Hai ottenuto una serie di ragioni, ma eccone un'altra: a prova di futuro. Prima o poi, man mano che la tua applicazione si evolve, ti verranno presentati alcuni requisiti che non possono essere raggiunti prontamente o in modo sicuro nel JS sul lato client o come procedura memorizzata nel tuo database.

Ad esempio, ti viene detto che tutte le nuove registrazioni devono avere una verifica CAPTCHA per essere valide. Questo sarebbe davvero abbastanza facile con praticamente qualsiasi moderno framework di applicazioni web. Basta schiaffeggiare un reCAPTCHA sul modulo di registrazione, passare il token di risposta di reCAPTCHA al back-end e aggiungere un paio di righe di codice al back-end per verificare la validità del token con l'API di Google (o meglio, utilizzare una libreria che qualcun altro ha scritto per farlo per te).

Se stai utilizzando un sistema a due livelli e fai affidamento sul database per tutta la tua logica lato server, come hai intenzione di verificare il token? Sì, suppongo che potrebbe essere teoricamente possibile a seconda del DBMS scrivere una procedura memorizzata che in qualche modo chiama una shell e invoca il ricciolo con gli argomenti appropriati. Anche questa è quasi certamente un'idea orribile: filtrare l'input e proteggere dalle vulnerabilità della sicurezza sarebbe terribile; avresti problemi a gestire errori e timeout; e dovresti analizzare tu stesso la risposta. Per non parlare del fatto che un DBMS non è destinato a farlo, quindi non c'è motivo di pensare che prestazioni, stabilità, sicurezza dei thread, ecc ... non siano problemi. Vedi, ad esempio, questo thread , che discute alcuni di questi problemi per Postgres.

E questo è solo il problema relativo all'aggiunta di un semplice CAPTCHA a un modulo. Cosa farai se desideri aggiungere la verifica SMS o un lavoro in background che invia agli utenti inattivi messaggi di posta elettronica per ricordare loro sulla tua app o aggiungere una funzione di caricamento dei file in modo che le persone possano impostare un'immagine del profilo? Forse decidi che la tua applicazione dovrebbe avere dei test automatici un giorno? O che desideri monitorare le modifiche alle tue procedure in un sistema di controllo della versione? Esistono numerose librerie e strumenti per la maggior parte di qualsiasi linguaggio utile per gestire la maggior parte di queste attività per te, ma pochi o nessuno saranno disponibili per il tuo DBMS, perché non è pensato per farlo.

Alla fine, vorrai fare qualcosa che non puoi ragionevolmente fare direttamente nel tuo DBMS, e poi rimarrai bloccato. Poiché avrai creato l'intera applicazione nel tuo DBMS, non avrai altra alternativa che ottenere un web server e iniziare a ricostruire pezzi in un'altra lingua, solo per aggiungere una semplice funzionalità.

E sarebbe un vero peccato, perché abbiamo già un nome per il luogo in cui si inserisce la logica dell'applicazione, e per un motivo si chiama "codice sorgente dell'applicazione" anziché "procedure memorizzate nel database".

Se i controlli di sicurezza e la logica aziendale sono contenuti nel javascript lato client, possono essere sovrascritti da un utente malintenzionato. In alternativa, è possibile sfruttare una tecnologia lato server basata su JavaScript (come Node.JS ) per gestire la convalida, l'autorizzazione e simili.

Qualsiasi vincolo aziendale che potresti voler garantire deve essere validato lato server. Anche se controlli l'accesso degli utenti, qualcuno potrebbe inviare dati non validi.

Seguendo l'esempio del clone di StackOverflow:

• Come impedirebbe comunque che le domande "chiuse" sul sito vengano modificate?
• Come impedire alle persone di eliminare i commenti?
• Come impedire alle persone di falsificare le date dei commenti?
• Come impediresti alle persone di effettuare l'upgrade di 50 volte lo stesso post?
• Probabilmente ci sono molti più esempi se scavi un po 'di più.

Chiunque potrebbe manipolare il codice lato client e violare completamente l'integrità dei dati (anche se limitato a determinati oggetti, come i propri post).

Modifica la pagina in firebug e ad un certo punto metti una linea simile a questa:

ExecDbCommand("DROP TABLE Users")

Eseguirlo.

Modificare:

La domanda riguardava infatti CounchDB, quindi non è possibile eseguire sql qui. Eppure l'idea è la stessa. Presumo che qualsiasi applicazione non banale dipenda dai dati per rispettare alcune regole di coerenza che sono controllate / applicate dal codice dell'applicazione. Un utente malintenzionato può modificare il codice client per salvare i dati in una forma che viola le regole aziendali e può causare il caos nell'applicazione.

Se il tuo sito considera tutti i possibili stati dei dati validi dal punto di vista commerciale, segui sicuramente questa strada, ma se ciò non è il caso (probabile), allora avresti la garanzia che tutti i dati che vengono memorizzati vengono generati dal tuo codice e secondo le tue regole .

Vecchia domanda, lo so, ma volevo entrare perché la mia esperienza è abbastanza diversa dalle altre risposte.

Ho trascorso molti anni a scrivere applicazioni collaborative in tempo reale. L'approccio generale per queste applicazioni è replicare i dati localmente e sincronizzare le modifiche con i peer il più rapidamente possibile. Tutte le operazioni sui dati sono locali, quindi tutti i livelli di archiviazione, accesso ai dati, logica aziendale e interfaccia utente sono livelli locali. Il movimento "offline first" ( http://offlinefirst.org/ ) ha adottato questo approccio per la creazione di applicazioni web offline e potrebbe disporre di alcune risorse rilevanti. Questi tipi di casi d'uso non richiedono solo l'apertura del livello di accesso ai dati ai client, ma anche l'archiviazione dei dati! Lo so, lo so. Sembra folle, vero?

Le preoccupazioni per tali prime app offline sono simili a quelle che hai chiesto, solo un livello rimosso. Mi sembra rilevante. Dato che stai aprendo l'accesso diretto ai dati ai client, la domanda diventa: come puoi limitare gli effetti di un utente malintenzionato? Bene, ci sono molte strategie, ma non sono ovvie se vieni da un background di sviluppo più tradizionale.

Il primo malinteso è che esporre il database significa esporre tutti i dati. Prendi CouchDB per esempio; i database in CouchDB sono leggeri, quindi non avresti un secondo pensiero sulla creazione di centinaia di migliaia di database separati su un server. Gli utenti possono solo accedere ai database a cui sono autorizzati ad accedere come lettori o scrittori (per non parlare delle funzionalità di convalida e di ciò che non è CouchDB), quindi possono accedere solo a un sottoinsieme dei dati.

Il secondo malinteso è che un utente che salta sui dati è un problema! Se gli utenti ricevono una replica di un database, possono cagare su tutto ciò che vogliono senza influenzare gli altri utenti. Tuttavia, è necessario convalidare le modifiche prima di replicare i dati nell'archivio "centrale". Pensa a Git: gli utenti possono fare ciò che vogliono in filiali, fork e repository locali senza influire sul ramo master. La fusione con il maestro implica molta cerimonia e non si fa alla cieca.

Attualmente sto costruendo un sistema utilizzando CouchDB in cui gli utenti devono collaborare ai dati per creare un set di dati che viene poi "pubblicato" tramite un flusso di lavoro QA / QC. La collaborazione viene effettuata su una replica dei dati (che chiamiamo database di gestione temporanea o di lavoro) e, una volta completata, una persona responsabile esegue il QA / QC sui dati e solo successivamente viene replicata nel repository principale.

Da questo derivano molti vantaggi che sono difficili da ottenere in altri sistemi, come il controllo delle versioni, la replica e la collaborazione (per non parlare del funzionamento offline!) Per le tradizionali applicazioni CRUD a tre livelli è super difficile.

Il mio consiglio: se la tua applicazione è "tradizionale", fallo nel modo tradizionale. Se una qualsiasi delle cose che ho menzionato sopra (anche se c'è molto di più ...) si applica a te, allora prendi in considerazione architetture alternative e preparati a pensare lateralmente.

Penso che, dati tutti i tuoi presupposti, sia possibile passare direttamente dal client al database. Tuttavia, è ragionevole verificare se i tuoi presupposti sono validi e probabilmente rimarranno tali in futuro.

Sarei preoccupato che in futuro potrebbe non essere corretto per tutti leggere tutti i dati e soprattutto che in futuro potrebbe sviluppare più logica di business. Entrambi sono più probabili se il progetto ha successo.

Fintanto che ti lascerai un modo per affrontare questi problemi in futuro quando e se davvero dovrai affrontarli, penso che il tuo design funzionerà. Penso che dovrai stare molto attento a separare le preoccupazioni nel codice JavaScript e alcune di queste potrebbero finire per essere riscritte sul server in seguito.

Ma potrei sicuramente vedere dove potrebbe valere la pena rischiare di farlo più tardi rispetto al beneficio di un minor numero di parti in movimento oggi.

Innanzitutto grazie per la domanda OUT OF THE BOX .... :)

Ma ciò che suggerirei è; Cerca sempre di mantenere una segregazione tra i tuoi 3 livelli. che sono Presentazione / Business e Database o DAO perché saranno le migliori pratiche in quei tipi di requisiti e configurazioni in cui ci saranno molte modifiche ogni giorno.

In mondi semplici il tuo livello Presentazione non dovrebbe conoscere il livello Database, ad esempio il formato di alcuni campi del tipo di data potrebbe essere diverso dal livello presentazione e dal livello database in modo che l'utente possa avere la libertà di selezionare il formato adatto della data secondo le sue esigenze.

E la logica di business deve agire come un accoppiamento tra il livello di presentazione e il livello di database / Dao come il casting dei campi, alcune convalide aziendali, ecc. Dovrebbero essere gestiti sul livello aziendale piuttosto che nella sezione Javascript come da domanda.

Questa segregazione ti fornirà grande facilità e comportamento durante scenari complessi, funzionalità e persino convalide complesse. Il vantaggio migliore è: è possibile disporre di tecnologie diverse per implementare questi livelli e possono essere modificati in base alle esigenze o all'ambito aziendale.

Grazie

Se si desidera creare SQL in JavaScript e inviarlo al database, che verifica i diritti ecc., Che per motivi di sicurezza sarebbe un disastro. Semplicemente perché quando si crea un'API e si creano query da soli, è necessario analizzare dal punto di vista della sicurezza solo il numero limitato di query. Se le query sono costruite al di fuori del tuo sistema, hai un numero potenzialmente illimitato di trucchi che qualcuno potrebbe fare.

Ma non è il caso dal momento che stai usando un database di valori-chiave (per quanto sia giusto, CouchDB generalmente rientra in quella categoria). L'interfaccia del database stessa è una sorta di livello intermedio ed è testata per motivi di sicurezza dal team Apache. A causa dell'API JavaScript relativamente semplice, questo è ancora più facile da analizzare per potenziali difetti rispetto a interfacce così complicate che hanno le applicazioni JSF.

Questa può essere una soluzione sicura se si eseguono test di sicurezza complessi. Questo può essere ancora più semplice come quando si utilizzano framework come JSF, che spesso utilizzano API difficilmente leggibili dietro. La sicurezza per oscurità non è considerata una soluzione.

In relazione alla tua domanda, non sarà comunque accesso diretto al database. L'accesso diretto sarebbe la creazione di query SQL in JavaScript (sfortunatamente, ho visto tali soluzioni). Nel tuo caso il CouchDB stesso fornisce il livello di isolamento. Ovviamente potresti avvolgerlo nella tua API per renderlo più duro, ma finché puoi facilmente provare cosa può fare un determinato utente e se i vincoli di sicurezza funzionano per te, avrai una soluzione sicura e robusta senza livelli aggiuntivi.

Vedo due problemi:

1. Accoppiamento stretto: modificare l'opzione DB? Bene, ora devi cambiare anche tutto il codice lato client. Fidati di me. Non abbiamo bisogno di più problemi sul lato client.

2. Problema di sicurezza TMI: rivela troppo su come funzionano le cose. Auth potrebbe essere ancora un ostacolo, ma trovare un exploit è un inferno molto più semplice quando sai esattamente cosa sta succedendo sul lato server.

Un livello medio molto magro potrebbe essere un modo migliore di procedere.

Il tuo client non può utilizzare la tua app Web se JavaScript è disabilitato (o non supportato dal browser del suo dispositivo) se JavaScript è l'unico livello di accesso al database.