Doğrudan istemci tarafındaki Javascript’ten bir veritabanına gitmemek için herhangi bir neden var mı?

Olası Çoğalt:
Web'e “sunucudan daha az” uygulamalar yazma

Diyelim ki bir Stack Exchange klonu oluşturacağım ve arka uç mağazam olarak CouchDB gibi bir şey kullanmaya karar verdim. Dahili kimlik doğrulama ve veritabanı düzeyinde yetkilendirme kullanırsam, istemci tarafı Javascript'in doğrudan herkese açık CouchDB sunucusuna yazmasına izin vermemek için herhangi bir neden var mı? Bu temelde bir CRUD uygulaması olduğundan ve iş mantığı “Sadece yazarın gönderisini düzenleyebiliyor” dan oluştuğundan, müşteri tarafı ile veri tabanı arasında bir katmana sahip olma gereği duymuyorum. Birinin çöp verilerini koymadığından ve izinlerin doğru ayarlandığından ve kullanıcıların yalnızca kendi _user verilerini okuyabildiğinden emin olmak için yalnızca CouchDB tarafında doğrulama kullanırdım. Render müşteri tarafında AngularJS gibi bir şey tarafından yapılabilir. Temelde bir CouchDB sunucusuna ve bir sürü "statik" sayfaya sahip olabilirsiniz ve gitmeniz iyi olur. Herhangi bir sunucu tarafı işlemeye ihtiyacınız olmaz, yalnızca HTML sayfalarını düzenleyebilecek bir şey kullanılır.

Veritabanımı dünyaya açmak yanlış görünüyor, ancak bu senaryoda izinlerin neden uygun şekilde verildiği sürece nedenini düşünemiyorum. Bir web geliştiricisi olarak içgüdülerime aykırı, ama iyi bir sebep düşünemiyorum. Peki, bu neden kötü bir fikir?

EDIT: Burada benzer bir tartışma var gibi görünüyor: Web "sunucu daha az" uygulamaları yazma

EDIT: Şimdiye kadarki müthiş tartışma ve herkesin geri bildirimini takdir ediyorum! Özellikle CouchDB ve AngularJS'i çağırmak yerine birkaç genel varsayım eklemem gerektiğini düşünüyorum. Öyleyse farz edelim ki:

• Veritabanı, kullanıcıları doğrudan gizli mağazalarından doğrulayabilir
• Tüm veritabanı iletişimi SSL üzerinden gerçekleşir
• Veri doğrulama olabilir (ama belki? Olmamalıdır) veritabanı tarafından ele
• Yönetici işlevlerinden başka umursadığımız tek yetkilendirme, yalnızca kendi gönderilerini düzenlemesine izin verilen bir kişidir.
• Tüm verileri okuyabilen herkes için gayet iyiyiz (şifre karmaları içerebilecek EXCEPT kullanıcı kayıtları)
• İdari işlevler, veritabanı yetkilendirmesiyle kısıtlanacaktır
• Hiç kimse kendilerini yönetici rolüne ekleyemez
• Veritabanının ölçeklendirilmesi nispeten kolaydır
• Gerçek bir iş mantığı yok denecek kadar azdır; Bu temel bir CRUD uygulaması

İstediğiniz gibi yapmak, müşteri tarafı dilinizle veritabanınız arasında sıkı bir bağlantı oluşturur.

Bu tamam olabilir - yazmak ve sürdürmek için daha az kod var ve teoride hata ayıklama biraz daha hızlı olabilir / gitmeli.

Öte yandan, diğer yönleri daha da zorlaştırıyor. Bu teknolojilerden herhangi birini değiştirmeniz gerektiğinde / gerektiğinde, aralarındaki sıkı bağlantı nedeniyle daha zor zamanlar geçirirsiniz.

Kendinizi saldırılara karşı korumak (oldukça) biraz daha zor olacak. Müşterinin her zaman veritabanına güzel bir şekilde biçimlendirilmiş istekler sunacağını varsayıyorsunuz. Bu, hiç kimsenin kötü niyetli ifadeler eklemek için hiç bir zaman müşteri tarafı kodunu kırmayacağını varsayar. Başka bir deyişle, kimlik doğrulama mekanizmalarınızı "ödünç alırlar" ve normal müşteri kodunu kendi kodlarıyla değiştirirler.

Bunu tavsiye etmem ve birçoğu şiddetle yapmamasını söylerdi. Ama olabilir yapılabilir.

Muhtemelen iyi bir fikir değil. Verebileceğim ilk ve en güçlü neden, bir veritabanı sunucusunun genel bir web sunucusu olarak tasarlanmamış olmasıdır . Aksine, geleneksel bilgelik, veritabanınızı bir güvenlik duvarının arkasına gizlemeniz gerektiğini söylüyor.

Destekleyici kanıtlara ihtiyacınız varsa, pek çok endişeniz var - bunların hepsi aşılmaz bir şey değil, aynı zamanda düşünülmesi gereken çok şey var. Belirli bir düzende, işte birkaçı:

• Sorgu temizleme işlemini gerçekleştiremiyor, çünkü sorguları doğrudan gönderiyorsunuz .
• Veritabanı izinleri, web sunucusu ve uygulama izinlerinden farklı çalışma eğilimindedir. Web sunucuları ve uygulama çerçeveleri sizi hiçbir şey ile başlatmaz ve bireysel kaynakları, son noktaları ve eylemleri açıkça oluşturmanız ve göstermeniz gerekir. Öte yandan, veritabanları sizden üst düzeyde roller vermenizi ister.
• Bir web sunucusunun iş yükünü sürdürmek için muhtemelen iyi optimize edilmiş değil; bağlantı havuzundan yararlanamazsınız.
• Daha popüler web sunucuları uğramakta olan bir sürü . Ve birçok güvenlik yaması aldılar. DBMS'iniz temel olarak bir güvenlik duvarının arkasına gizlenecek şekilde tasarlanmıştır, bu yüzden muhtemelen halka açık web'de karşılaşacakları potansiyel tehditlerin yüzde kadarı bile test edilmemiştir.
• Sen gerekir özel verileri korumak için veritabanının sorgu dilini kullanırlar. DBMS'nize bağlı olarak, bu zor olabilir.
• Sen gerekir büyük veri kümelerini filtrelemek için veritabanının sorgu dilini kullanma - yine yapmaya gayret olabilecekleri bir şeyi; ama daha karmaşık iş kuralları için ağır olabilen bir şey.
• Üçüncü taraf kütüphaneleri için sınırlı destek veya destek yok.
• Karşılaştığınız sorunların çoğu için çok sınırlı (potansiyel olarak sıfır) topluluk desteği.

... Ve eminim başka endişeler var. Ve eminim ki çoğu için bir çözüm vardır - eğer bu endişelerin tümü değilse. Ama başlaman için bir liste var!

Hayal edebileceğim en iyi neden şudur: çünkü bu yöntem doğrudan ilgili taraflarca desteklenmiyor veya tavsiye edilmiyor.

Tarayıcı satıcıları, EcmaScript standartları, veritabanı sistemi geliştiricileri, ağ ekipmanı şirketleri, barındırma / altyapı mimarları ve güvenlik uzmanları, önerilen kullanım durumunuzu aktif olarak desteklemiyor (veya belki de dikkate alıyorsunuz). Bu bir sorundur, çünkü önerilen yönteminiz tüm bu varlıkların - ve daha fazlasının - uygulamanız için uygun şekilde çalışmasını gerektirmektedir, buna rağmen ilgili sistemlerin hiçbiri bunu desteklemek için tasarlanmamıştır.

Bunun mümkün olmadığını söylemiyorum. Sadece bunun daha az "tekerleği yeniden icat etmek" ve daha çok tarayıcı tabanlı istemci-sunucu etkileşimini yeniden icat etmek gibi olduğunu söylüyorum.

En iyi ihtimalle, sistemlerin mümkün olan en temel seviyede çalışmasını sağlamak için bir ton iş yapacaksınız. Modern popüler veritabanları RESTful değildir veya HTTP üzerinden çalışmak üzere oluşturulmamıştır, bu nedenle kendi WebSocket tabanlı (Sanırım) istemci sürücülerinizi oluşturacaksınız.

Teknik olarak çalışacak her şeyi elde etseniz bile, modern mimarilerin en güçlü özelliklerinden vazgeçeceksiniz. Derinlemesine savunma yapamazsınız - herkes doğrudan web sitesi hackleme girişimlerinin birincil hedefine kolayca bağlanabilir. Ancak önerdiğiniz senaryo bundan çok daha kötüdür.

Önerilen model yalnızca sunucuyu göstermiyor - geçerli bağlantı dizelerini de gösteriyor. Saldırganlar sadece sunucuya ping atamazlar - aktif olarak giriş yapabilir ve komutlarını besleyebilirler. Veri erişimini sınırlasanız bile, DBMS sistemlerinde Hizmet Reddi senaryolarından ve ilklerinden korunmak için yeterli araç kullanmanın farkında değilim. TSQL gibi gelişmiş SQL sürümlerinde çalışırken, etkili bir şekilde sonsuz sayıda çalışan bombalar üretmek genellikle çok kolaydır (kartezyen bir ürün üretmek için sınırsız sayıda bağlantı sağlar ve sonsuza dek koşacak bir SEÇİM elde edersiniz) . JOIN'lerle birlikte temel SELECT sorgularını ortadan kaldırarak ve belki de yalnızca saklı yordamları çağırmaya izin vererek SQL'in özelliklerinin çoğunu devre dışı bırakmanız gerekeceğini hayal ediyorum. Bunu yapıp yapamayacağımı bile bilmiyorum, asla denemem istenmedi. Öyle değil

Veritabanı ölçeklenebilirliği, büyük ölçeklerde çalışırken en zor sorunlardan biri olma eğilimindeyken, birden çok HTTP sunucusunu - özellikle statik veya önbelleğe alınmış sayfalarla - ölçeklendirmenin en kolay kısımlarından biridir. Teklifiniz, sunucu tarafındaki faaliyetlerin% 100'ünden sorumlu olarak veritabanının daha fazla çalışmasını sağlar. Bu tek başına bir katil kusur. Çalışmayı müşteriye taşıyarak elde ettiğiniz kazanım, veritabanına daha çok çalışmayı taşıyarak kaybedersiniz.

Son olarak, sadece önerdiğiniz şeyin kalbinin yeni olmadığını, aslında on yıllara dayandığını belirtmek isterim. Bu modele, temelde çoğu sunucu tarafı mantığını istediğiniz gibi veritabanına yerleştiren "yağ veritabanı" modeli denir. Bu modelin kitlesel internette bir kenara girmesinin birçok sebebi var ve muhtemelen bu tarihe daha fazla bakmanız çok bilgilendirici olacaktır. Ayrıca, o zaman bile, tamamen sisteme giriş yapabilen ve komutları çalıştırabilen tamamen güvenilmeyen kullanıcıların, sisteme sürekli olarak saldırması beklenmeyen dahili (bilinen) kullanıcıları seçmek için kontrol edilebileceği konusunda çok az şey olduğuna dikkat edin.

Gerçek şu ki, dosya sunmak için hala bir HTTP sunucusuna ihtiyacınız olacak, çünkü veritabanı sistemleri bunu yapmıyor. Aynı zamanda, teklif ettiğiniz her şey, veritabanınıza RESTful bir arayüz göstermek için ince bir sunucu modeli (Nodejs gibi) kullanarak elde edilebilir. Bu bir nedenden ötürü popülerdir - çalışır, veritabanını koruma katmanlarının arkasına gizlenmiş halde tutar, aşırı ölçeklenebilirdir ve yine de veritabanınızı istediğiniz kadar kalın veya ince olarak oluşturmanıza olanak tanır.

Bu temelde bir CRUD uygulaması olduğundan ve iş mantığı “Sadece yazarın gönderisini düzenleyebiliyor” olduğundan oluşur. Birinin çöp verilerini koymadığından ve izinlerin doğru ayarlandığından ve kullanıcıların yalnızca kendi _user verilerini okuyabildiğinden emin olmak için yalnızca CouchDB tarafında doğrulama kullanırdım.

Eh, senin yerleştirerek yetki Veritabanı uzak (güvenlik kaygıları) ve mantık doğrulama endişeleri ayrılmasını sağlayan yazılım sisteminde. Böylece, mantıksal kod bloklarınızı sistemdeki işlevselliği daha az frenleme riskiyle test edebilir, bakımını yapabilir, ölçeklendirebilir ve yeniden kullanabilirsiniz.

İstemci girişinin doğrudan Veritabanı ile iletişim kurmasını sağlamak , verileri bozma potansiyeline sahiptir .

Bu ayrıca, sıkı kaplinlerden kaçınmanın / çıkarmanın , yazılım sisteminizi daha sürdürülebilir ve SOLID hale getirdiği anlamına gelir .

Kullanıcının doğrudan veritabanıyla etkileşime girmesine izin vermek benim için gerçekten tehlikeli görünüyor.

CouchDB'nin kimlik doğrulama mekanizması, bir kullanıcının okuma ve yazma erişimini yalnızca okuması ve yazması gereken verilere ayırabilmeniz için gerçekten o kadar karmaşık mıdır (belge başına, belki alan başına erişim bile ayrıcalıklar burada)? Birden fazla kullanıcı tarafından paylaşılan "ortak" verilerden ne haber? Bu, uygulama tasarımınızda hiç mevcut değil mi?

Kullanıcının verilerini herhangi bir şekilde değiştirebilmesini gerçekten istiyor musunuz? Mesela XSS enjeksiyonlarından ne haber? Veritabanına girmeden önce bunları filtrelemek için bir sunucu katmanının olması daha iyi olmaz mıydı?

Bir takım nedenler aldınız, fakat işte bir tane daha: geleceğe dair koruma. Er ya da geç, uygulamanız geliştikçe, müşteri tarafındaki JS'de veya veritabanında saklı bir prosedür olarak kolayca veya güvenli bir şekilde elde edilemeyen bir gereksinim sunulur.

Örneğin, tüm yeni kayıtların geçerli olması için bir CAPTCHA doğrulamasının yapılması gerektiği söylenir. Bu, herhangi bir modern web uygulaması çerçevesiyle, gerçekten de yeterince kolay olacaktır. Kayıt formunda bir reCAPTCHA'yı tokatlayın, reCAPTCHA'nın yanıt belirtecini arka uca geri iletin ve belirtecin Google'ın API'siyle geçerliliğini doğrulamak için arka uçunuza birkaç satır kod ekleyin (ya da daha iyisi, bunu yapmak için başka birinin yazdığı bir kitaplığı kullanın) senin için).

İki katmanlı bir sistem kullanıyorsanız ve tüm sunucu tarafı mantığınız için veritabanına güveniyorsanız, belirteci nasıl doğrulayacaksınız? Evet, DBMS'ye bağlı olarak bir şekilde bir kabuk çağıran ve uygun argümanlarla kıvrılmaya çağıran saklı bir prosedür yazmanın teorik olarak mümkün olabileceğini tahmin ediyorum. Bu da neredeyse kesinlikle korkunç bir fikir: girdilerin filtrelenmesi ve güvenlik açıklarına karşı korunma korkunç olurdu; hataların ele alınması ve zaman aşımları ile ilgili bir karmaşa yaşarsınız; ve cevabı kendin ayrıştırman gerek Bir DBMS'nin bunu yapması amaçlanmadığından bahsetmiyorum bile, performans, istikrar, iş güvenliği vb. Sorun olmayacağını düşünmek için hiçbir sebep yok. Örneğin, bakınız, bu parçacığı Postgres için bu sorunlardan bazılarını ele.

Ve bu sadece bir forma basit bir CAPTCHA eklemekle ilgili konular. SMS doğrulaması eklemek veya etkin olmayan kullanıcılara uygulamanız hakkında hatırlatmaları için e-posta gönderen bir arka plan işi eklemek veya kişilerin bir profil resmi oluşturabilmesi için bir dosya yükleme özelliği eklemek isterseniz ne yapacaksınız? Belki uygulamanızın bir gün bazı otomatik testler yapması gerektiğine karar verdiniz? Veya sürüm kontrol sistemindeki prosedürlerinizdeki değişiklikleri takip etmek mi istiyorsunuz? Bu görevlerin çoğunu sizin için halledecek en kullanışlı dil için çok sayıda kitaplık ve araç var, ancak DBMS'iniz için çok azı yok.

Sonunda, doğrudan DBMS'nizde makul bir şekilde yapamayacağınız bir şey yapmak isteyeceksiniz ve daha sonra sıkışıp kalacaksınız. Uygulamanızın tümünü DBMS’nize kurduğunuz için, bir web sunucusu almak ve parçaları başka bir dilde yeniden oluşturmaya başlamaktan başka basit bir özellik eklemek için hiçbir seçeneğiniz olmayacak.

Ve bu gerçek bir utanç olurdu, çünkü zaten uygulama mantığınızı koyduğunuz yer için bir adımız vardı ve buna bir nedenden ötürü "veritabanı saklı yordamları" yerine "uygulamanızın kaynak kodu" deniyor.

Güvenlik kontrolleriniz ve iş mantığınız müşteri tarafınızda javascript'te bulunuyorsa, kötü niyetli bir kullanıcı tarafından geçersiz kılınabilir. Alternatif olarak, doğrulama, yetkilendirme ve benzeri işlemleri yapmak için JavaScript tabanlı bir sunucu tarafı teknolojisinden ( Node.JS gibi ) yararlanabilirsiniz.

Güvence altına almak isteyebileceğiniz tüm işletme kısıtlamaları, sunucu tarafında doğrulanmalıdır. Kullanıcı erişimini kontrol etseniz bile, birisi geçersiz veri gönderebilir.

Stackoverflow klon örneğinizin ardından:

• Sitedeki "kapalı" soruların yine de düzenlenmesini nasıl engellersiniz?
• İnsanların yorumları silmesini nasıl önlersiniz?
• İnsanların yorum tarihlerini taklit etmelerini nasıl önlersiniz?
• İnsanların aynı gönderinin 50 katını kaldırmasını nasıl önlersiniz?
• Biraz daha kazarsanız, muhtemelen çok daha fazla örnek var.

Herhangi biri müşteri tarafı kodunu değiştirebilir ve veri bütünlüğünü tamamen ihlal edebilir (kendi nesnelerindeki gibi bazı nesnelerle sınırlı olsa bile).

Firebug’daki sayfayı düzenleyin ve bir noktada şuna benzer bir satır ekleyin:

ExecDbCommand("DROP TABLE Users")

Koş

Düzenle:

Asıl soru CounchDB hakkındaydı, burada çalıştırmak için hiçbir sql yoktu. Oysa fikir aynı. Önemsiz olmayan herhangi bir uygulamanın, uygulama kodu tarafından kontrol edilen / uygulanan bazı tutarlılık kurallarına uymak için verilere bağlı olduğunu varsayardım. Kötü niyetli bir kullanıcı, iş kurallarınızı ihlal eden ve uygulamanızda hasara neden olabilecek bir biçimde veri kaydetmek için müşteri kodunu değiştirebilir.

Siteniz tüm olası veri durumlarını işletme açısından geçerli buluyorsa, o zaman elbette bu rotayı takip edin, ancak bu gerçekleşmezse (muhtemel değilse), saklanan verilerin sizin tarafınızdan üretileceğini garanti altına almak istersiniz . kodunu ve kurallarına göre .

Eski bir soru, biliyorum, ama merak etmek istedim çünkü deneyimlerim diğer tepkilerden oldukça farklı.

Yıllarca gerçek zamanlı, işbirliğine dayalı uygulamalar yazmakla geçirdim. Bu uygulamalar için genel yaklaşım, verileri yerel olarak çoğaltmak ve değişiklikleri olabildiğince hızlı eşler ile senkronize etmektir. Verilerdeki tüm işlemler yerel olduğundan, tüm veri depolama, veri erişimi, iş mantığı ve kullanıcı arabirimi yereldir. "Çevrimdışı ilk" hareketi ( http://offlinefirst.org/ ), çevrimdışı web uygulamaları oluşturmak için bu yaklaşımı benimsemiştir ve bazı ilgili kaynaklara sahip olabilir. Bu tür kullanım durumları yalnızca veri erişim katmanınızı istemcilere açmanızı değil, aynı zamanda veri depolamanızı da zorunlu kılar! Biliyorum biliyorum. Delice görünüyor, değil mi?

Bu tür çevrimdışı ilk uygulamalar için endişeler sorduklarına benzer, sadece bir seviye kaldırıldı. Bu benim için alakalı görünüyor. Müşterilere doğrudan veri erişimi açtığınızı göz önüne alındığında, soru şu olur: Kötü niyetli bir kullanıcının etkilerini nasıl sınırlayabilirsiniz? Pek çok strateji var, ancak daha geleneksel bir kalkınma geçmişinden geliyorsanız, belli değiller.

İlk yanlış anlama, veritabanının açığa çıkarılması, tüm verileri açığa çıkarmak anlamına gelir. Örneğin CouchDB'yi kullanın; CouchDB'deki veritabanları hafiftir, bu nedenle bir sunucuda yüzbinlerce ayrı veritabanı oluşturma hakkında ikinci bir fikriniz olmaz. Kullanıcılar yalnızca bir okuyucu veya yazar olarak erişim izni verilen veritabanlarına erişebilir (yalnız doğrulama özellikleri ve CouchDB'nin ne olmadığı), böylece yalnızca verilerin bir alt kümesine erişebilirler.

İkinci yanılgı, kullanıcının veriyi kırması bir problem olduğu! Kullanıcılara bir veritabanının kopyası verilirse, diğer kullanıcıları etkilemeden istedikleri her şeyi silebilirler. Ancak, verilerini tekrar "merkezi" depoya çoğaltmadan önce değişikliklerini doğrulamanız gerekir. Git'i düşünün - kullanıcılar ana dalını etkilemeden dallarda, çatallarda ve yerel depolarda istediklerini yapabilirler. Usta ile yeniden bir araya gelmek çok fazla tören gerektirir ve kör yapılmaz.

Şu anda CouchDB kullanarak, daha sonra bir KG / KK iş akışı aracılığıyla "yayınlanan" bir veri kümesi oluşturmak için kullanıcıların veriler üzerinde işbirliği yapması gereken bir sistem kuruyorum. İşbirliği verilerin bir kopyası üzerinde gerçekleştirilir (buna aşamalı veya çalışan bir veritabanı diyoruz) ve tamamlandığında, sorumlu bir kişi veri üzerinde KG / KK gerçekleştirir ve yalnızca bundan sonra ana depoya çoğaltılır.

Geleneksel üç aşamalı CRUD uygulamaları için sürüm kontrolü, çoğaltma ve işbirliği (çevrimdışı çalışmayı bırakın!) Gibi diğer sistemlerde elde edilmesi zor olan pek çok fayda bundan çok zor.

Tavsiyem - Başvurunuz "geleneksel" ise, geleneksel yöntemle yapın. Yukarıda bahsettiğim şeylerden herhangi biri (daha fazlası olsa da ...) sizin için geçerliyse, alternatif mimarileri göz önünde bulundurun ve yanal düşünmeye hazır olun.

Tüm varsayımlarınız göz önüne alındığında, doğrudan müşteriden veri tabanına gitmek mümkün olduğunu düşünüyorum. Bununla birlikte, varsayımlarınızın geçerli olup olmadığına ve gelecekte de öyle kalacağının muhtemel olduğuna bakmak makul olacaktır.

Gelecekte, tüm verileri okumak için herkesin uygun olmayacağından ve özellikle gelecekte daha fazla iş mantığı geliştirebileceğinden endişe ediyorum. Bunların ikisi de, eğer proje başarılı olursa daha muhtemeldir.

Gelecekte bu sorunlarla başa çıkmak için bir yol bıraktığınız sürece, aslında onlarla başa çıkmanız gerektiğinde tasarımınızın işe yarayacağını düşünüyorum. JavaScript kodundaki kaygıları ayırmak için daha dikkatli olmanız gerektiğini düşünüyorum ve bunun bir kısmı daha sonra sunucuda yazılabilir.

Ancak, bugün daha az hareketli parçanın yararına karşı belki bunu daha sonra yapmanın riskinin ne kadar değerli olabileceğini kesinlikle görebiliyordum.

Öncelikle KUTU DIŞI soru için teşekkürler .... :)

Ama önereceğim şey; Her zaman 3 katmanınız arasında bir ayrışma sağlamaya çalışın. Hangi Sunum / İş ve Veri Tabanı veya DAO'dur ki, bu her gün çok fazla değişikliğin olacağı bu tür gereksinimler ve kurulumlarda en iyi uygulama olacaktır.

Basit dünyalarda Sunum katmanınız Veritabanı katmanını bilmemelidir, yani bazı tarih türü alanlarının formatı sunum katmanından ve veritabanı katmanından farklı olabilir, böylece kullanıcı isteğine göre tarihin uygun formatını seçme özgürlüğüne sahip olabilir.

İş Mantığı, sunum katmanı ile veritabanı / Dao katmanı arasında bir bağlantı gibi davranmalı, alanların dökülmesi, bazı işletme onaylamaları vb., Sorunuza göre Javascript bölümünde değil, İş Katmanında ele alınmalıdır.

Bu ayrışma size karmaşık senaryolar, işlevsellikler ve hatta karmaşık onaylamalar sırasında büyük kolaylık ve uyum sağlayacaktır. En iyi avantaj: Bu katmanları uygulamak için farklı teknolojilere sahip olabilir ve iş gereksinimlerine veya kapsamına göre değiştirilebilir.

Teşekkürler

SQL’i JavaScript’te oluşturmak ve hakları, vb. Doğrulayan veritabanına göndermek istiyorsanız, güvenlik nedeniyle felaket olur. Bunun nedeni bir API oluşturduğunuzda ve kendiniz sorgular oluşturduğunuzda, güvenlik açısından yalnızca sınırlı sayıda sorguyu analiz etmeniz gerekir. Sorgular sisteminizin dışına yerleştirilmişse, birinin yapabileceği sınırsız sayıda püf noktaya sahip olabilirsiniz.

Ancak, anahtar-değer veritabanını kullandığınız için durum böyle değil (anladığım kadarıyla, CouchDB genellikle bu kategoriye giriyor). Veritabanı arayüzünün kendisi bir tür orta katmandır ve güvenlik nedeniyle Apache ekibi tarafından test edilmiştir. Nispeten basit JavaScript API'si nedeniyle, potansiyel kusurları analiz etmek JSF uygulamalarının sahip olduğu karmaşık arayüzlerden daha kolaydır.

Karmaşık güvenlik testleri yaparsanız, bu güvenli bir çözüm olabilir. Bu, genellikle arkasından zor okunabilen API kullanan JSF gibi çerçeveler kullanıldığında olduğu gibi daha da kolay olabilir. Gizliliğin olmadığı güvenlik, çözüm olarak kabul edilmez.

Sorunuzla ilgili olarak, yine de veritabanına doğrudan erişim olmayacaktır. Doğrudan erişim, JavaScript’te SQL sorguları oluşturmak olacaktır (ne yazık ki, böyle çözümler gördüm). Sizin durumunuzda CouchDB'nin kendisi izolasyon katmanı sağlar. Elbette sertleştirmek için API'nize sarabilirsiniz, ancak belirli bir kullanıcının neler yapabileceğini kolayca test edebildiğiniz sürece ve güvenlik kısıtlamaları sizin için çalışıyorsa, ek katmanlar olmadan güvenli ve sağlam bir çözüme sahip olacaksınız.

İki problem görüyorum:

1. Sıkı Kavrama: DB seçeneğini değiştirir misiniz? Şimdi, tüm müşteri tarafı kodunu değiştirmelisin. Güven Bana. Müşteri tarafında daha fazla soruna ihtiyacımız yok.

2. TMI Güvenlik Sorunu: İşlerin nasıl yürüdüğü hakkında çok fazla şey ortaya çıkıyor. Yetkilendirme hala engel olabilir, ancak istismar bulmak sunucu tarafında tam olarak ne olduğunu bildiğinde çok daha kolay bir cehennemdir.

Çok çok ince bir orta kademe daha iyi bir yol olabilir.

Javascript tek veritabanı erişim katmanı ise, javascript devre dışı bırakılmışsa (veya cihazının tarayıcısında desteklenmiyorsa) müşteriniz web uygulamanızı kullanamaz.