Apakah ada alasan untuk tidak langsung pergi dari Javascript sisi klien ke database?

Kemungkinan Duplikat:
Menulis aplikasi "server kurang" Web

Jadi, katakanlah saya akan membangun klon Stack Exchange dan saya memutuskan untuk menggunakan sesuatu seperti CouchDB sebagai toko backend saya. Jika saya menggunakan otentikasi bawaan dan otorisasi tingkat basis data, apakah ada alasan untuk tidak mengizinkan Javascript sisi klien untuk menulis langsung ke server CouchDB yang tersedia untuk umum? Karena ini pada dasarnya adalah aplikasi CRUD dan logika bisnis terdiri dari "Hanya penulis yang dapat mengedit posting mereka" Saya tidak melihat banyak kebutuhan untuk memiliki lapisan antara hal-hal sisi klien dan database. Saya hanya akan menggunakan validasi di sisi CouchDB untuk memastikan seseorang tidak memasukkan data sampah dan memastikan bahwa izin diatur dengan benar sehingga pengguna hanya dapat membaca data pengguna _ mereka sendiri. Render akan dilakukan sisi klien dengan sesuatu seperti AngularJS. Intinya Anda hanya bisa memiliki server CouchDB dan banyak halaman "statis" dan Anda siap melakukannya. Anda tidak memerlukan pemrosesan sisi server apa pun, hanya sesuatu yang dapat melayani halaman HTML.

Membuka basis data saya ke dunia tampaknya salah, tetapi dalam skenario ini saya tidak dapat memikirkan mengapa selama izin ditetapkan dengan benar. Itu bertentangan dengan naluriku sebagai pengembang web, tapi aku tidak bisa memikirkan alasan yang bagus. Jadi, mengapa ini ide yang buruk?

EDIT: Sepertinya ada diskusi serupa di sini: Menulis aplikasi Web "server kurang"

EDIT: Diskusi yang luar biasa sejauh ini, dan saya menghargai umpan balik semua orang! Saya merasa saya harus menambahkan beberapa asumsi umum daripada memanggil CouchDB dan AngularJS secara khusus. Jadi mari kita asumsikan bahwa:

• Basis data dapat mengotentikasi pengguna langsung dari toko tersembunyi
• Semua komunikasi basis data akan terjadi melalui SSL
• Validasi data dapat (tetapi mungkin tidak?) Ditangani oleh database
• Satu-satunya otorisasi yang kami pedulikan selain fungsi admin adalah seseorang hanya diizinkan mengedit posting mereka sendiri
• Kami baik-baik saja dengan semua orang dapat membaca semua data (KECUALI catatan pengguna yang mungkin berisi hash kata sandi)
• Fungsi administratif akan dibatasi oleh otorisasi basis data
• Tidak ada yang bisa menambahkan diri mereka ke peran administrator
• Basis data relatif mudah untuk diukur
• Ada sedikit atau tidak ada logika bisnis sejati; ini adalah aplikasi CRUD dasar

Melakukan apa yang Anda sarankan menciptakan hubungan yang erat antara bahasa sisi klien Anda dan basis data Anda.

Itu bisa oke - ada sedikit kode untuk ditulis dan dipelihara, dan secara teori debugging bisa / harus berjalan sedikit lebih cepat.

Di sisi lain, itu membuat aspek-aspek lain lebih sulit. Jika / ketika Anda perlu mengubah salah satu dari teknologi itu, Anda akan memiliki waktu yang lebih sulit karena ikatan yang erat di antara mereka.

Melindungi diri Anda dari serangan akan (cukup) sedikit lebih sulit. Anda berasumsi bahwa klien akan selalu menyajikan permintaan yang diformat dengan baik ke database. Itu mengandaikan tidak ada yang akan meretas kode sisi klien untuk memasukkan pernyataan berbahaya. Dengan kata lain, mereka akan "meminjam" mekanisme otentikasi Anda dan mengganti kode klien normal dengan mereka.

Saya tidak akan merekomendasikan hal ini, dan banyak yang dengan keras akan memberitahu Anda untuk tidak melakukannya. Tapi itu bisa dilakukan.

Itu mungkin bukan ide yang bagus. Dan alasan pertama dan terkuat yang dapat saya berikan adalah bahwa server database tidak dirancang untuk menjadi server web publik. Sebaliknya, kebijakan konvensional mengatakan Anda harus menyembunyikan basis data Anda di balik firewall.

Jika Anda membutuhkan bukti pendukung, ada banyak kekhawatiran - tidak semua tidak dapat diatasi, tetapi banyak untuk dipikirkan. Tanpa urutan tertentu, berikut adalah beberapa:

• Itu tidak dapat melakukan sanitasi permintaan, karena Anda mengirimkannya permintaan secara langsung.
• Izin basis data cenderung berfungsi berbeda dari izin server web dan aplikasi. Server web dan kerangka kerja aplikasi memulai Anda tanpa apa-apa, dan Anda perlu secara eksplisit membuat dan mengekspos sumber daya individu, titik akhir, dan tindakan. Database, di sisi lain, meminta Anda untuk memberikan peran di level tinggi.
• Mungkin tidak dioptimalkan dengan baik untuk mempertahankan beban kerja server web; Anda tidak bisa mendapat manfaat dari koneksi pooling.
• Server web yang lebih populer telah dipecah menjadi banyak . Dan mereka telah menerima banyak tambalan keamanan. DBMS Anda pada dasarnya dirancang untuk bersembunyi di balik firewall, jadi mungkin belum diuji oleh sebagian kecil dari potensi ancaman yang akan dihadapi di web publik.
• Anda harus menggunakan bahasa permintaan basis data untuk melindungi data pribadi. Tergantung pada DBMS Anda, itu bisa jadi menantang.
• Anda harus menggunakan bahasa kueri basis data untuk memfilter kumpulan data besar - sesuatu yang mungkin ingin Anda lakukan; tetapi sesuatu yang dapat menjadi beban bagi aturan bisnis yang lebih rumit.
• Dukungan terbatas atau tidak sama sekali untuk perpustakaan pihak ketiga.
• Dukungan komunitas sangat terbatas (berpotensi nol) untuk banyak masalah yang akan Anda hadapi.

... Dan saya yakin ada kekhawatiran lain. Dan saya yakin ada solusi untuk sebagian besar - jika tidak semua masalah ini. Tapi, ada daftar untuk memulai!

Alasan tunggal terbaik yang dapat saya bayangkan adalah: karena metode ini tidak secara langsung didukung atau direkomendasikan oleh pihak yang terlibat.

Vendor browser, standar EcmaScript, pengembang sistem basis data, perusahaan peralatan jaringan, arsitek hosting / infrastruktur, dan spesialis keamanan tidak secara aktif mendukung (atau bahkan mungkin mempertimbangkan) kasus penggunaan yang Anda usulkan. Ini adalah masalah, karena metode yang Anda usulkan memerlukan semua entitas ini - dan lebih banyak lagi - untuk bekerja dengan tepat untuk aplikasi Anda, meskipun tidak ada sistem yang terlibat yang dirancang untuk mendukung ini.

Saya tidak mengatakan itu tidak mungkin. Saya hanya mengatakan ini kurang seperti "re-inventing the wheel" dan lebih seperti re-inventing interaksi client-server berbasis browser.

Paling-paling, Anda akan melakukan banyak pekerjaan bahkan untuk mendapatkan sistem untuk bekerja pada tingkat paling dasar yang mungkin. Database populer modern tidak tenang atau dibangun untuk bekerja melalui HTTP, sehingga Anda akan membangun driver klien Anda sendiri berbasis WebSocket (saya kira).

Bahkan jika Anda mendapatkan semuanya berfungsi secara teknis, Anda akan meninggalkan banyak fitur paling kuat dari arsitektur modern. Anda tidak akan memiliki pertahanan mendalam - setiap orang dapat dengan mudah terhubung langsung ke target utama dari sebagian besar upaya peretasan situs web. Tetapi skenario yang Anda usulkan jauh, jauh lebih buruk dari itu.

Model yang diusulkan tidak hanya mengekspos server - itu mengekspos string koneksi yang valid. Penyerang tidak bisa hanya ping server - mereka dapat secara aktif login dan memberi makan perintah itu. Bahkan jika Anda dapat membatasi akses data, saya tidak mengetahui adanya tooling yang memadai dalam sistem DBMS untuk melindungi dari skenario Denial of Service dan sejenisnya. Ketika bekerja dalam versi SQL yang disempurnakan, seperti TSQL, seringkali mudah untuk menghasilkan bom yang berjalan secara efektif tanpa batas (beberapa bergabung tanpa batas untuk menghasilkan produk Cartesian dan Anda akan memiliki SELECT yang akan berjalan selamanya, melakukan pekerjaan berat) . Saya membayangkan Anda harus menonaktifkan sebagian besar fitur SQL, bahkan menghilangkan pertanyaan SELECT dasar dengan GABUNG dan mungkin hanya mengizinkan pemanggilan prosedur tersimpan? Saya bahkan tidak tahu apakah Anda bisa melakukan itu, saya tidak pernah diminta untuk mencobanya. Tidak

Skalabilitas basis data juga cenderung menjadi salah satu masalah tersulit dalam bekerja pada skala besar, sementara scaling out beberapa server HTTP - terutama dengan halaman statis atau cache - adalah salah satu bagian yang paling mudah. Proposal Anda membuat basis data lebih berfungsi dengan bertanggung jawab atas pada dasarnya 100% aktivitas sisi server. Itu adalah kesalahan pembunuh dengan sendirinya. Apa yang Anda peroleh dari memindahkan pekerjaan ke klien yang Anda hilangkan dengan memindahkan lebih banyak pekerjaan ke basis data.

Akhirnya, saya hanya ingin menunjukkan bahwa inti dari apa yang Anda usulkan bukanlah hal yang baru, tetapi sebenarnya sudah ada beberapa dekade yang lalu. Model ini disebut model "database gemuk", yang pada dasarnya memindahkan sebagian besar logika sisi-server ke dalam basis data seperti yang Anda usulkan. Ada banyak alasan bahwa model telah pergi di pinggir jalan di internet massal, dan mungkin akan informatif untuk melihat lebih dalam sejarah itu sendiri. Perhatikan juga bahwa bahkan pada saat itu ada sedikit pertimbangan bahwa pengguna yang benar-benar tidak dipercaya dapat masuk ke sistem dan menjalankan perintah, karena akses masih akan dikontrol untuk memilih pengguna internal (dikenal) yang tidak seharusnya menyerang sistem secara terus-menerus.

Faktanya adalah bahwa Anda masih memerlukan server HTTP untuk menyajikan file, karena sistem basis data tidak melakukannya. Pada saat yang sama, semua yang Anda usulkan dapat diperoleh dengan menggunakan model server tipis (seperti dengan Nodejs) untuk mengekspos antarmuka yang tenang ke database Anda. Ini populer karena suatu alasan - ini berfungsi, membuat basis data tersembunyi jauh di belakang lapisan perlindungan, sangat terukur, namun memungkinkan Anda untuk membangun basis data Anda setebal atau setipis yang Anda mau.

Karena ini pada dasarnya adalah aplikasi CRUD dan logika bisnis terdiri dari "Hanya penulis yang dapat mengedit posting mereka" Saya tidak melihat banyak kebutuhan untuk memiliki lapisan antara hal-hal sisi klien dan database. Saya hanya akan menggunakan validasi di sisi CouchDB untuk memastikan seseorang tidak memasukkan data sampah dan memastikan bahwa izin diatur dengan benar sehingga pengguna hanya dapat membaca data pengguna _ mereka sendiri.

Nah, menempatkan otorisasi Anda (masalah keamanan) dan validasi logika dari Database memberikan pemisahan masalah dalam sistem perangkat lunak Anda. Dengan demikian Anda dapat menguji, memelihara, skala dan menggunakan kembali blok kode logis Anda dengan risiko pengereman fungsionalitas dalam sistem lebih sedikit.

Memberikan kemampuan untuk input klien secara langsung berkomunikasi dengan Database memiliki potensi yang sangat besar untuk mengacaukan data .

Ini juga berarti bahwa menghindari / menghapus kopling ketat membuat sistem perangkat lunak Anda lebih mudah dirawat dan SOLID.

Membiarkan pengguna berinteraksi dengan database secara langsung tampaknya sangat berbahaya bagi saya.

Apakah mekanisme otentikasi CouchDB benar-benar sangat canggih sehingga Anda dapat mengisolasi akses baca dan tulis pengguna hanya ke data yang seharusnya dibaca dan ditulis (kita berbicara tentang per-dokumen, bahkan mungkin akses per-dokumen-bidang) hak istimewa di sini)? Bagaimana dengan data "komunal" yang dibagikan oleh banyak pengguna? Apakah ini tidak ada sama sekali dalam desain aplikasi Anda?

Apakah Anda benar-benar ingin pengguna dapat mengubah datanya dengan cara APA PUN? Bagaimana dengan suntikan XSS, misalnya? Bukankah lebih baik memiliki layer server untuk menyaring mereka sebelum mereka masuk ke dalam database?

Anda memiliki sejumlah alasan, tetapi ada satu alasan lagi: pembuktian di masa depan. Cepat atau lambat, ketika aplikasi Anda berkembang, Anda akan dihadapkan dengan beberapa persyaratan yang tidak dapat dengan mudah atau aman dicapai di JS sisi klien atau sebagai prosedur tersimpan dalam database Anda.

Misalnya, Anda diberi tahu bahwa semua pendaftaran baru harus memiliki verifikasi CAPTCHA agar valid. Ini akan sangat mudah dengan hampir semua kerangka kerja aplikasi web modern. Cukup tampar reCAPTCHA pada formulir pendaftaran, berikan token respons reCAPTCHA kembali ke backend, dan tambahkan beberapa baris kode ke backend Anda untuk memverifikasi validitas token dengan Google API (atau lebih baik lagi, gunakan perpustakaan yang ditulis orang lain untuk melakukan itu untukmu).

Jika Anda menggunakan sistem dua tingkat dan mengandalkan database untuk semua logika sisi server Anda, bagaimana Anda akan memverifikasi token? Ya, saya kira mungkin secara teori tergantung pada DBMS untuk menulis prosedur tersimpan yang entah bagaimana memanggil shell dan memanggil curl dengan argumen yang tepat. Itu juga hampir pasti merupakan ide yang mengerikan: penyaringan input dan perlindungan terhadap kerentanan keamanan akan mengerikan; Anda akan memiliki masalah berurusan dengan penanganan kesalahan dan batas waktu; dan Anda harus menguraikan respons sendiri. Belum lagi bahwa DBMS tidak dimaksudkan untuk melakukan ini, jadi tidak ada alasan untuk berpikir kinerja, stabilitas, keamanan thread, dll ... tidak akan menjadi masalah. Lihat, misalnya, utas ini , yang membahas beberapa masalah ini untuk Postgres.

Dan itu hanya masalah sekitar menambahkan satu CAPTCHA sederhana ke formulir. Apa yang akan Anda lakukan jika Anda ingin menambahkan verifikasi SMS, atau pekerjaan latar belakang yang mengirimkan email kepada pengguna yang tidak aktif untuk mengingatkan mereka tentang aplikasi Anda, atau menambahkan fitur unggah file sehingga orang dapat mengatur gambar profil? Mungkin Anda memutuskan aplikasi Anda harus memiliki beberapa tes otomatis suatu hari nanti? Atau Anda ingin melacak perubahan pada prosedur Anda dalam sistem kontrol versi? Ada banyak perpustakaan dan alat untuk sebagian besar bahasa yang berguna untuk menangani sebagian besar tugas ini untuk Anda, tetapi sedikit atau tidak ada yang tersedia untuk DBMS Anda, karena itu tidak dimaksudkan untuk melakukan ini.

Akhirnya, Anda akan ingin melakukan sesuatu yang tidak dapat Anda lakukan secara langsung di DBMS Anda, dan kemudian Anda akan mandek. Karena Anda telah membangun seluruh aplikasi dalam DBMS, Anda tidak akan memiliki alternatif selain mendapatkan server web dan mulai membangun kembali potongan-potongan dalam bahasa lain, hanya untuk menambahkan fitur sederhana.

Dan itu akan sangat memalukan, karena kami sudah memiliki nama untuk tempat di mana Anda meletakkan logika aplikasi Anda, dan itu disebut "kode sumber aplikasi Anda" daripada "prosedur tersimpan basis data" karena suatu alasan.

Jika pemeriksaan keamanan dan logika bisnis Anda terkandung dalam javascript sisi klien Anda, mereka dapat ditimpa oleh pengguna jahat. Sebagai alternatif, Anda dapat memanfaatkan teknologi sisi server berbasis JavaScript (seperti Node.JS ) untuk menangani validasi, otorisasi, dan sejenisnya.

Batasan bisnis apa pun yang Anda ingin pastikan harus divalidasi di sisi server. Bahkan jika Anda mengontrol akses pengguna, seseorang dapat mengirim data yang tidak valid.

Berikut contoh clone stackoverflow Anda:

• Bagaimana cara Anda memblokir pertanyaan "tertutup" di situs agar tidak diedit?
• Bagaimana Anda mencegah orang menghapus komentar?
• Bagaimana Anda mencegah orang memalsukan tanggal komentar?
• Bagaimana Anda mencegah orang menaikkan 50 kali pos yang sama?
• Mungkin ada lebih banyak contoh jika Anda menggali sedikit lebih banyak.

Siapa pun dapat memanipulasi kode sisi klien dan melanggar integritas data sepenuhnya (bahkan jika terbatas pada objek tertentu, seperti pos mereka sendiri).

Edit halaman di firebug dan pada beberapa titik letakkan baris yang mirip dengan ini:

ExecDbCommand("DROP TABLE Users")

Menjalankannya.

Sunting:

Pertanyaannya sebenarnya tentang CounchDB sehingga tidak ada sql untuk dijalankan di sini. Namun idenya sama. Saya akan menganggap bahwa aplikasi non-sepele tergantung pada data untuk menghormati beberapa aturan konsistensi yang diperiksa / diberlakukan oleh kode aplikasi. Seorang pengguna jahat dapat memodifikasi kode klien untuk menyimpan data dalam bentuk yang melanggar aturan bisnis Anda dan dapat menyebabkan kekacauan dalam aplikasi Anda.

Jika situs Anda menganggap semua status data yang mungkin valid dari perspektif bisnis maka dengan segala cara pergi rute ini tetapi jika ini tidak terjadi (kemungkinan) maka Anda ingin memiliki jaminan bahwa data yang disimpan disimpan oleh Anda kode dan sesuai dengan aturan Anda .

Pertanyaan lama, saya tahu, tetapi saya ingin berbincang karena pengalaman saya sangat berbeda dengan tanggapan lainnya.

Saya telah menghabiskan bertahun-tahun menulis aplikasi kolaboratif waktu-nyata. Pendekatan umum untuk aplikasi ini adalah mereplikasi data secara lokal dan menyinkronkan perubahan dengan rekan sesegera mungkin. Semua operasi pada data adalah lokal, jadi semua penyimpanan data, akses data, logika bisnis dan antarmuka pengguna adalah lapisan adalah lokal. Gerakan "offline pertama" ( http://offlinefirst.org/ ) telah mengadopsi pendekatan ini untuk membangun aplikasi web offline dan mungkin memiliki beberapa sumber daya yang relevan. Jenis kasus penggunaan ini tidak hanya mengharuskan Anda membuka lapisan akses data ke klien, tetapi juga penyimpanan data! Saya tahu saya tahu. Tampak gila, kan?

Kekhawatiran untuk aplikasi offline-pertama semacam itu mirip dengan apa yang Anda minta, hanya satu tingkat dihapus. Tampaknya relevan bagi saya. Mengingat Anda membuka akses data langsung ke klien, pertanyaannya menjadi, bagaimana Anda dapat membatasi efek pengguna jahat? Ya, ada banyak strategi, tetapi itu tidak jelas jika Anda berasal dari latar belakang pembangunan yang lebih tradisional.

Kesalahpahaman pertama adalah bahwa mengekspos database berarti mengekspos semua data. Ambil CouchDB misalnya; basis data di CouchDB ringan, sehingga Anda tidak perlu berpikir untuk membuat ratusan ribu basis data terpisah di server. Pengguna hanya dapat mengakses basis data bahwa mereka diberikan izin untuk mengakses sebagai pembaca atau penulis (apalagi fitur validasi dan apa-apa dari CouchDB), sehingga mereka hanya dapat mengakses subkumpulan data.

Kesalahpahaman kedua adalah bahwa pengguna melakukan crapping pada data adalah masalah! Jika pengguna diberi replika database maka mereka dapat melakukan semua yang mereka suka tanpa mempengaruhi pengguna lain. Tetapi, Anda harus memvalidasi perubahan mereka sebelum mereplikasi data mereka kembali ke toko "pusat". Pikirkan tentang Git - pengguna dapat melakukan apa yang mereka suka di cabang, garpu dan repositori lokal tanpa mempengaruhi cabang master. Penggabungan kembali ke master melibatkan banyak upacara dan tidak dilakukan secara membabi buta.

Saya sedang membangun sistem saat ini menggunakan CouchDB di mana pengguna perlu berkolaborasi pada data untuk membangun dataset yang kemudian "diterbitkan" melalui alur kerja QA / QC. Kolaborasi ini dilakukan pada replika data (kami menyebutnya sebagai staging atau database yang berfungsi), dan setelah selesai, orang yang bertanggung jawab melakukan QA / QC pada data dan hanya setelah itu direplikasi kembali ke repositori utama.

Banyak manfaat mengalir dari hal ini yang sulit dicapai di sistem lain - seperti kontrol versi, replikasi, dan kolaborasi (biarkan bekerja secara offline!) Untuk aplikasi CRUD tiga tingkat tradisional sangat sulit.

Saran saya - jika aplikasi Anda "tradisional" maka lakukan dengan cara tradisional. Jika ada hal-hal yang saya sebutkan di atas (walaupun ada banyak lagi ...) berlaku untuk Anda maka pertimbangkan arsitektur alternatif dan bersiaplah untuk berpikir lateral.

Saya pikir, mengingat semua asumsi Anda, layak untuk langsung pergi dari klien ke database. Namun, masuk akal untuk melihat apakah asumsi Anda valid, dan kemungkinan akan tetap demikian di masa depan.

Saya akan khawatir bahwa di masa depan mungkin tidak apa-apa bagi semua orang untuk membaca semua data, dan terutama bahwa itu mungkin mengembangkan lebih banyak logika bisnis di masa depan. Kedua hal ini lebih mungkin jika proyek berhasil.

Selama Anda meninggalkan diri Anda cara untuk mengatasi masalah ini di masa depan ketika dan jika Anda benar-benar perlu mengatasinya, saya pikir desain Anda akan bekerja. Saya pikir Anda harus ekstra hati-hati untuk memisahkan masalah dalam kode JavaScript, dan beberapa di antaranya mungkin akan ditulis ulang di server nanti.

Tapi saya pasti bisa melihat di mana itu mungkin layak risiko mungkin melakukan itu nanti vs manfaat lebih sedikit bagian yang bergerak hari ini.

Pertama-tama terima kasih atas pertanyaan KELUAR DARI KOTAK .... :)

Tapi yang saya sarankan adalah; Selalu berusaha mempertahankan pemisahan antara 3 lapisan Anda. yang Presentasi / Bisnis dan Database atau DAO karena itu akan menjadi praktik terbaik dalam jenis persyaratan dan pengaturan di mana akan ada banyak perubahan setiap hari.

Dalam dunia sederhana, lapisan Presentasi Anda tidak boleh tahu tentang lapisan Database yaitu Format beberapa bidang tipe tanggal mungkin berbeda dari lapisan presentasi dan lapisan database sehingga pengguna dapat memiliki kebebasan untuk memilih format tanggal yang sesuai sesuai kebutuhannya.

Dan Logika Bisnis harus bertindak seperti penggabungan antara lapisan presentasi dan basis data / lapisan Dao seperti casting bidang, beberapa validasi bisnis, dll. Harus ditangani pada Layer Bisnis daripada di bagian Javascript sesuai pertanyaan Anda.

Segregasi ini akan memberikan Anda kemudahan dan perubahan yang besar selama skenario kompleks, fungsionalitas dan bahkan validasi kompleks. Keuntungan terbaik adalah: Anda dapat memiliki teknologi berbeda untuk mengimplementasikan lapisan ini dan dapat diubah sesuai kebutuhan atau ruang lingkup bisnis.

Terima kasih

Jika Anda ingin membangun SQL dalam JavaScript dan mengirimkannya ke database, yang memverifikasi hak, dll., Daripada dari alasan keamanan itu akan menjadi bencana. Hanya karena ketika Anda membangun API, dan membuat sendiri kueri, Anda harus menganalisis dari sudut pandang keamanan hanya jumlah kueri yang terbatas. Jika kueri dibuat di luar sistem Anda, Anda berpotensi memiliki sejumlah trik yang bisa dilakukan seseorang.

Tapi itu tidak terjadi karena Anda menggunakan basis data nilai kunci (sejujur ​​yang saya mengerti, CouchDB umumnya termasuk dalam kategori itu). Antarmuka basis data itu sendiri adalah semacam lapisan tengah, dan itu diuji untuk alasan keamanan oleh tim Apache. Karena API JavaScript yang relatif sederhana, ini bahkan lebih mudah untuk dianalisis untuk kelemahan potensial daripada antarmuka rumit yang dimiliki aplikasi JSF.

Ini bisa menjadi solusi yang aman, jika Anda melakukan tes keamanan yang rumit. Ini bahkan bisa lebih mudah ketika menggunakan kerangka kerja seperti JSF, yang sering menggunakan API yang sulit dibaca. Keamanan oleh ketidakjelasan dianggap tidak ada solusi.

Berkaitan dengan pertanyaan Anda, itu tidak akan menjadi akses langsung ke database. Akses langsung akan menjadi permintaan SQL bangunan dalam JavaScript (sayangnya, saya sudah melihat solusi seperti itu). Dalam kasus Anda, CouchDB itu sendiri menyediakan lapisan isolasi. Anda tentu saja dapat membungkusnya dalam API Anda untuk mengeraskannya, tetapi selama Anda dapat dengan mudah menguji apa yang dapat dilakukan pengguna tertentu dan jika kendala keamanan bekerja untuk Anda, Anda akan memiliki solusi yang aman dan kuat tanpa lapisan tambahan.

Saya melihat dua masalah:

1. Tight Coupling: Ubah opsi DB Anda? Nah, sekarang Anda harus mengubah semua kode sisi klien Anda juga. Percayalah kepadaku. Kami tidak membutuhkan lebih banyak masalah di sisi klien.

2. Masalah Keamanan TMI: Mengungkap terlalu banyak tentang cara kerja barang. Auth mungkin masih menjadi kendala tetapi menemukan exploit adalah neraka yang jauh lebih mudah ketika Anda tahu persis apa yang terjadi di sisi server.

Tingkat menengah yang sangat-sangat-tipis mungkin cara yang lebih baik.

Klien Anda tidak dapat menggunakan aplikasi web Anda jika javascript dinonaktifkan (atau tidak didukung di browser perangkatnya) jika javascript adalah satu-satunya lapisan akses basis data.