クライアント側のJavascriptからデータベースに直接移動しない理由はありますか？

重複の可能性：
Web「サーバーレス」アプリケーションの作成

そこで、Stack Exchangeクローンを構築し、CouchDBのようなものをバックエンドストアとして使用することにしたとしましょう。組み込みの認証とデータベースレベルの承認を使用する場合、クライアント側のJavaScriptが公開されているCouchDBサーバーに直接書き込むことを許可しない理由はありますか？これは基本的にCRUDアプリケーションであり、ビジネスロジックは「投稿者のみが投稿を編集できる」で構成されているため、クライアント側のものとデータベースの間にレイヤーを配置する必要はほとんどありません。CouchDB側で検証を使用して、誰かがガベージデータを入れていないことを確認し、ユーザーが自分の_userデータしか読み取れないようにアクセス許可が適切に設定されていることを確認します。レンダリングは、AngularJSのようなものによってクライアント側で行われます。本質的には、CouchDBサーバーと多数の「静的」ページを用意するだけで十分です。サーバー側の処理は一切必要なく、HTMLページを提供できるものだけが必要です。

データベースを世界中に公開するのは間違っているように見えますが、このシナリオでは、アクセス許可が適切に設定されている限り、その理由を考えることはできません。Web開発者としての私の本能に反しますが、正当な理由は考えられません。それで、なぜこれは悪い考えですか？

編集：同様の議論がここにあるように見えます：Web「サーバーレス」アプリケーションの作成

編集：これまでのところ素晴らしい議論、そして私は皆のフィードバックに感謝します！CouchDBとAngularJSを具体的に呼び出す代わりに、いくつかの一般的な仮定を追加する必要があるように感じます。だからそれを仮定しましょう：

• データベースは、非表示のストアからユーザーを直接認証できます。
• すべてのデータベース通信はSSL経由で行われます
• データ検証をすることができます（多分？べきではありません）データベースによって処理され
• 管理機能以外に私たちが気にする唯一の承認は、自分の投稿の編集のみが許可されている人
• 誰でもすべてのデータを読み取ることができます（パスワードハッシュを含む可能性があるユーザーレコードを除く）
• 管理機能は、データベース認証によって制限されます
• 誰も管理者ロールに自分を追加できません
• データベースは比較的簡単に拡張できます
• 真のビジネスロジックはほとんどありません。これは基本的なCRUDアプリです

提案どおりに実行すると、クライアント側の言語とデータベースの間に緊密な結合が作成されます。

それは大丈夫です-書いて維持するコードが少なくなり、理論的にはデバッグが少し速くなるはずです。

一方で、それは他の側面をより困難にします。これらのテクノロジーのいずれかを変更する必要がある場合、それらの間の密結合のために苦労します。

攻撃から身を守ることは（かなり）少し難しくなります。クライアントは常に適切にフォーマットされたリクエストをデータベースに提示すると仮定しています。誰もクライアント側のコードをハッキングして悪意のあるステートメントを挿入することはないと想定しています。言い換えれば、彼らはあなたの認証メカニズムを「借り」、通常のクライアントコードを彼らのものに置き換えます。

私はそれを推奨しません。しかし、それはできます。

おそらく素晴らしいアイデアではありません。そして、私が説明できる最初で最も強力な理由は、データベースサーバーがパブリックWebサーバーとして設計されていないことです。それどころか、従来の知識では、データベースをファイアウォールの内側に隠すべきだと言われています。

裏付けとなる証拠が必要な場合、多くの懸念があります。すべてを乗り越えることはできませんが、考えることはたくさんあります。順不同で、以下にいくつかを示します。

• クエリを直接送信しているため、クエリのサニタイズを実行できません。
• データベースのアクセス許可は、Webサーバーおよびアプリケーションのアクセス許可とは異なる動作をする傾向があります。Webサーバーとアプリケーションフレームワークは何も開始せず、個々のリソース、エンドポイント、およびアクションを明示的に作成および公開する必要があります。一方、データベースでは、高いレベルでロールを付与するように求められます。
• Webサーバーのワークロードを維持するために最適化されていない可能性があります。接続プーリングの恩恵を受けることはできません。
• より人気のあるWebサーバーは多くに分割されています。そして、彼らは多くのセキュリティパッチを受け取りました。DBMSは基本的にファイアウォールの背後に隠れるように設計されているため、パブリックWebで直面する可能性のある潜在的な脅威のほんの数パーセントでもテストされていない可能性があります。
• プライベートデータを保護するには、データベースのクエリ言語を使用する必要があります。DBMSによっては、難しい場合があります。
• あなたはしなければならない大規模なデータセットをフィルタリングするために、データベースのクエリ言語を使用する-あなたはとにかくやるために努力かもしれない何かを。しかし、より複雑なビジネスルールにとっては負担になることがあります。
• サードパーティライブラリのサポートは制限されているか、サポートされていません。
• あなたが遭遇する多くの問題に対する非常に限られた（潜在的にゼロ）コミュニティサポート。

...そして、私は他の懸念があると確信しています。そして、これらすべての懸念事項ではないにしても、ほとんどの解決策があると確信しています。しかし、始めるためのリストがあります！

私が想像できる最良の単一の理由は、この方法が関係者によって直接サポートまたは推奨されていないためです。

ブラウザーベンダー、EcmaScript標準、データベースシステム開発者、ネットワーク機器会社、ホスティング/インフラストラクチャアーキテクト、およびセキュリティスペシャリストは、提案されたユースケースを積極的にサポートしません（または検討することさえありません）。これは問題です。関連するシステムはどれもこれをサポートするように設計されていませんが、提案された方法ではこれらのすべてのエンティティ（およびそれ以上）がアプリケーションに適切に機能する必要があるためです。

私はそれが不可能だと言っているのではありません。これは「車輪の再発明」ではなく、ブラウザベースのクライアント/サーバー相互作用の再発明に似ていると言っています。

せいぜい、システムを可能な限り最も基本的なレベルで動作させるために、大量の作業を行うことになるでしょう。最近の人気のあるデータベースはRESTfulではなく、HTTPで動作するように構築されていないため、独自のWebSocketベース（おそらく）クライアントドライバーを構築することになります。

すべてを技術的に機能させたとしても、現代のアーキテクチャの最も強力な機能の多くを放棄することになります。多層防御は行われません。ほとんどのWebサイトハッキングの主な標的に誰でも簡単に直接接続できます。しかし、あなたが提案するシナリオはそれよりもはるかに悪いです。

提案されたモデルは、サーバーを公開するだけでなく、有効な接続文字列を公開しています。攻撃者はサーバーにpingするだけでなく、コマンドに積極的にログインしてフィードすることができます。データアクセスを制限できたとしても、サービス拒否のシナリオとその脅威から保護するためのDBMSシステムの十分なツールについては知りません。TSQLなどの拡張バージョンのSQLで作業する場合、効果的に無限に実行される爆弾を作成するのは簡単です（デカルト製品を作成するための無制限の結合がいくつかあり、永遠に実行されるSELECTがあり、重い作業を行います） 。SQLのほとんどの機能を無効にし、JOINで基本的なSELECTクエリを削除し、おそらくストアドプロシージャの呼び出しのみを許可する必要があると思いますか？あなたがそれができるかどうかさえわかりません、私は試してみるように頼まれたことはありません。ありません

データベースのスケーラビリティは、大規模での作業において最も困難な問題の1つである傾向がありますが、複数のHTTPサーバーのスケールアウトは、特に静的ページまたはキャッシュページの場合、最も簡単な部分の1つです。あなたの提案は、サーバー側のアクティビティの基本的に100％を担当することにより、データベースにさらに多くの仕事をさせます。それ自体が致命的な欠陥です。より多くの作業をデータベースに移動することで失う作業をクライアントに移動することで得られるもの。

最後に、あなたが提案するものの核心は新しいものではなく、実際には数十年前に遡ることを指摘したいと思います。このモデルは「脂肪データベース」モデルと呼ばれ、基本的にほとんどのサーバー側のロジックを提案どおりにデータベースに移動しました。多くの理由から、モデルが大衆インターネット上で道を進んできたので、おそらくその歴史をもっと自分で調べることは有益でしょう。また、システムへのログインとコマンドの実行を完全に信頼できないユーザーに許可することはほとんど考慮されていないことにも注意してください。

実際のところ、データベースシステムはそれを行わないため、ファイルを提供するためにHTTPサーバーが必要になるということです。同時に、シンサーバーモデル（Nodejsなど）を使用してRESTfulインターフェイスをデータベースに公開することで、提案するすべてのものを取得できます。これが理由で人気があります-動作し、保護層の背後にデータベースを隠し、非常にスケーラブルでありながら、思いのままの厚さまたは薄さでデータベースを構築できます。

これは基本的にCRUDアプリケーションであり、ビジネスロジックは「投稿者のみが投稿を編集できる」で構成されているため、クライアント側のものとデータベースの間にレイヤーを配置する必要はほとんどありません。CouchDB側で検証を使用して、誰かがガベージデータを入れていないことを確認し、ユーザーが自分の_userデータしか読み取れないようにアクセス許可が適切に設定されていることを確認します。

さて、あなたの置く認証データベースから離れた（セキュリティ上の問題）と、論理検証することは 関心事の分離を提供お使いのソフトウェアシステムでは。したがって、システムの機能を破壊するリスクを軽減しながら、論理コードブロックをテスト、保守、スケーリング、および再利用できます。

クライアント入力がデータベースと直接通信する能力を提供することは、データを台無しにする非常に大きな可能性を持っています。

これは、密結合を回避/除去することで、ソフトウェアシステムのメンテナンス性と安定性が向上することも意味します。

ユーザーがデータベースと直接やり取りできるようにすることは、私にとって本当に危険に思えます。

CouchDBの認証メカニズムは本当に洗練されているので、ユーザーの読み取りおよび書き込みアクセスを、読み取りおよび書き込みが想定されているデータのみに分離できます（ドキュメントごと、またはドキュメントフィールドごとのアクセスについても説明しています）ここの特権）？複数のユーザーが共有する「共同」データについてはどうですか？これは、アプリケーション設計にまったく存在しませんか？

ユーザーがデータを任意の方法で変更できるようにしたいですか？たとえば、XSSインジェクションはどうですか？それらがデータベースに入る前にそれらをフィルタリングするサーバー層を持っている方が良いと思いませんか？

いくつかの理由がありますが、もう1つは、将来性を保証することです。遅かれ早かれ、アプリケーションの進化に伴い、クライアント側のJSで、またはデータベース内のストアドプロシージャとして容易にまたは安全に達成できない要件が表示されます。

たとえば、すべての新規登録を有効にするにはCAPTCHA検証が必要であると言われています。これは、ほとんどすべての最新のWebアプリケーションフレームワークで非常に簡単です。ただ、平手打ちreCAPTCHAのを、登録フォームにトークンバック、バックエンドにreCAPTCHAのの応答を渡し、まだGoogleのAPI（またはより良いとトークンの有効性を確認するためにあなたのバックエンドに数行のコードを追加し、他の誰かがそれを行うために書いたライブラリを使用しますあなたのために）。

2層システムを使用しており、サーバー側のすべてのロジックをデータベースに依存している場合、トークンをどのように検証しますか？はい、DBMSに応じて、何らかの方法でシェルを呼び出し、適切な引数でcurlを呼び出すストアドプロシージャを記述することは、理論的には可能であると思われます。それはほぼ間違いなく恐ろしいアイデアです。入力のフィルタリングとセキュリティの脆弱性からの保護はひどいでしょう。エラー処理とタイムアウトを処理するのは面倒です。自分で応答を解析する必要があります。DBMSがこれを行うことを意図していないことは言うまでもないので、パフォーマンス、安定性、スレッドセーフなどを問題にしないと考える理由はありません。たとえば、Postgresのこれらの問題のいくつかについて説明しているこのスレッドを参照してください。

そしてそれは、1つの単純なCAPTCHAをフォームに追加することに関する問題です。SMS検証を追加する場合、または非アクティブなユーザーにメールを送信してアプリについて通知するバックグラウンドジョブを追加する場合、またはユーザーがプロフィール写真を設定できるようにファイルアップロード機能を追加する場合はどうしますか？たぶん、あなたのアプリケーションはいつか自動化されたテストを行うべきだと決めたのでしょうか？または、バージョン管理システムで手順の変更を追跡したいですか？これらのタスクのほとんどを処理するためのほとんどの便利な言語用のライブラリとツールは多数ありますが、DBMSで使用できるものはほとんどないため、DBMSで使用できるものはほとんどありません。

最終的には、DBMSで直接合理的に実行できないことを実行したいと思うようになります。DBMSでアプリケーション全体を構築したので、単純な機能を追加するためだけに、Webサーバーを取得して別の言語でピースの再構築を開始する以外に選択肢はありません。

アプリケーションロジックを配置する場所の名前は既にあり、理由は「データベースストアドプロシージャ」ではなく「アプリケーションのソースコード」と呼ばれているためです。

セキュリティチェックとビジネスロジックがクライアント側のJavaScriptに含まれている場合、悪意のあるユーザーによって上書きされる可能性があります。別の方法として、JavaScriptベースのサーバー側テクノロジー（Node.JSなど）を活用して、検証、承認などを処理できます。

確認する必要があるビジネス上の制約は、サーバー側で検証する必要があります。ユーザーアクセスを制御しても、誰かが無効なデータを送信する可能性があります。

stackoverflowクローンの例に従ってください：

• とにかくサイト上の「閉じた」質問が編集されるのをどのようにブロックしますか？
• 人々がコメントを削除するのをどのように防止しますか？
• 人々がコメントの日付を偽造するのをどのように防止しますか？
• 人々が同じ投稿を50回支持するのをどのように防止しますか？
• もう少し掘り下げると、おそらくもっと多くの例があります。

誰でもクライアント側のコードを操作し、データの整合性に完全に違反する可能性があります（独自の投稿など、特定のオブジェクトに制限されている場合でも）。

firebugでページを編集し、ある時点で次のような行を追加します。

ExecDbCommand("DROP TABLE Users")

それを実行します。

編集：

質問は実際にはCounchDBに関するものであったため、ここで実行するSQLはありません。しかし、考え方は同じです。自明ではないアプリケーションは、アプリケーションコードによってチェック/適用される一貫性ルールを尊重するためにデータに依存していると思います。悪意のあるユーザーは、クライアントコードを変更して、ビジネスルールに違反する形式でデータを保存し、アプリケーションに混乱を引き起こす可能性があります。

サイトがすべての可能なデータ状態をビジネスの観点から有効であると見なす場合、必ずこのルートに進みますが、そうでない場合（おそらく）、保存されるデータはすべて自分で生成されることを保証したいでしょうコードとルールに従って。

古い質問ですが、私の経験は他の回答とはかなり異なるため、私はチャイムを鳴らしたかったのです。

私は長年、リアルタイムの共同アプリケーションを作成してきました。これらのアプリケーションの一般的なアプローチは、データをローカルで複製し、可能な限り高速でピアと変更を同期することです。データに対するすべての操作はローカルであるため、データストレージ、データアクセス、ビジネスロジック、およびユーザーインターフェイスはすべてレイヤーです。「オフライン優先」運動（http://offlinefirst.org/）は、オフラインWebアプリケーションを構築するためにこのアプローチを採用しており、いくつかの関連リソースがある場合があります。これらの種類のユースケースでは、データアクセスレイヤーをクライアントに開放するだけでなく、データストレージも義務付けています。分かってる。狂ったようですね。

このようなオフライン優先アプリの懸念は、あなたが尋ねたものに似ており、1レベルだけ削除されました。私には関係があるようです。クライアントへの直接データアクセスを許可している場合、問題は、悪意のあるユーザーの影響をどのように制限できるかということです。さて、多くの戦略がありますが、より伝統的な開発のバックグラウンドから来た場合、それらは明らかではありません。

最初の誤解は、データベースの公開はすべてのデータの公開を意味するというものです。CouchDBを例にとります。CouchDBのデータベースは軽量であるため、サーバー上に数十万の個別のデータベースを作成することについて考え直す必要はありません。ユーザーは、リーダーまたはライターとしてのアクセス許可が付与されているデータベースにのみアクセスできます（検証機能やCouchDBの機能はもちろん）、データのサブセットにのみアクセスできます。

2番目の誤解は、ユーザーがデータを取得するのが問題だということです。ユーザーにデータベースのレプリカが与えられると、他のユーザーに影響を与えることなく、好きなようにデータベースを複製できます。ただし、データを「中央」ストアに複製する前に、変更を検証する必要があります。Gitについて考えてください-ユーザーは、マスターブランチに影響を与えることなく、ブランチ、フォーク、ローカルリポジトリで好きなことを実行できます。マスターにマージすることは多くのセレモニーを伴い、盲目的に行われません。

現在、CouchDBを使用してシステムを構築しています。ユーザーは、QA / QCワークフローを介して「公開」されるデータセットを構築するために、データ上で共同作業する必要があります。コラボレーションはデータのレプリカ（これをステージングデータベースまたは作業データベースと呼びます）で実行され、完了すると、責任者がデータに対してQA / QCを実行し、その後メインリポジトリにレプリケートされます。

これにより、従来の3層CRUDアプリケーションのバージョン管理、複製、共同作業（オフライン作業も一緒に！）など、他のシステムでは実現が困難な多くのメリットが得られません。

私のアドバイス-あなたのアプリケーションが「伝統的」なら、それを伝統的な方法でやってください。上記で述べたことのいずれかが（もっとたくさんありますが...）あなたに当てはまる場合は、代替アーキテクチャを検討し、横方向に考える準備をしてください。

すべての前提を考えると、クライアントからデータベースに直接移動することは可能だと思います。ただし、仮定が有効であり、将来もそうである可能性が高いかどうかを確認することは合理的です。

将来、誰もがすべてのデータを読むことは問題ないかもしれないこと、特に将来的にはより多くのビジネスロジックを開発するかもしれないと心配します。プロジェクトが成功した場合、これらの両方が発生する可能性が高くなります。

将来これらの問題に対処する方法を自分で残しておけば、実際に対処する必要がある場合は、設計が機能すると思います。JavaScriptコード内の懸念事項を区別するために、さらに注意が必要であり、その一部は後でサーバー上で書き直される可能性があると思います。

しかし、おそらくそれを後で行うリスクと、今日の可動部品の数を減らすことのメリットがどこにあるのかを明確に知ることができました。

まず最初に、箱から出した質問に感謝します。...:)

しかし、私が提案するのは、常に3つのレイヤー間の分離を維持するようにしてください。これは、プレゼンテーション/ビジネスおよびデータベースまたはDAOです。これは、毎日多くの変更が行われるような種類の要件やセットアップでのベストプラクティスになるためです。

シンプルな世界では、プレゼンテーションレイヤーはデータベースレイヤーについて知らない必要があります。つまり、一部の日付型フィールドの形式はプレゼンテーションレイヤーやデータベースレイヤーと異なるため、ユーザーは必要に応じて適切な日付形式を選択できます。

また、ビジネスロジックは、フィールドのキャスト、一部のビジネス検証など、プレゼンテーションレイヤーとデータベース/ Daoレイヤー間のカップリングのように動作する必要があります。質問ごとに、JavaScriptセクションではなくビジネスレイヤーで処理する必要があります。

この分離は、複雑なシナリオ、機能、さらには複雑な検証においても、非常に簡単で快適に対応します。最大の利点は、これらのレイヤーを実装するためのさまざまなテクノロジーを使用でき、ビジネスニーズまたは範囲に応じて変更できることです。

ありがとう

SQLをJavaScriptで構築し、データベースに送信して、権限などを確認したい場合は、セキュリティ上の理由から災害になります。単に、APIを構築し、自分でクエリを構築する場合、セキュリティの観点から限られた数のクエリのみを分析する必要があるからです。クエリがシステムの外部で作成されている場合、潜在的に無制限の数のトリックを使用できます。

ただし、Key-Valueデータベースを使用しているため、そうではありません（私が理解する限り、CouchDBは一般的にそのカテゴリに分類されます）。データベースインターフェイス自体は一種の中間層であり、Apacheチームによってセキュリティ上の理由でテストされています。JavaScript APIは比較的単純であるため、JSFアプリケーションにあるような複雑なインターフェースよりも、潜在的な欠陥を分析するのがさらに簡単です。

複雑なセキュリティテストを行う場合、これは安全なソリューションになります。これは、JSFなどのフレームワークを使用する場合のように、さらに簡単になる可能性があります。JSFは、ほとんど読みにくいAPIを使用しています。あいまいさによるセキュリティは解決策とは見なされません。

あなたの質問に関連して、とにかくデータベースに直接アクセスすることはありません。直接アクセスは、JavaScriptでSQLクエリを構築することです（残念ながら、このようなソリューションを見てきました）。あなたの場合、CouchDB自体が分離レイヤーを提供します。もちろん、それを強化するためにAPIでラップすることもできますが、特定のユーザーができることを簡単にテストでき、セキュリティの制約が機能している場合は、追加のレイヤーなしで安全で堅牢なソリューションが得られます。

次の2つの問題があります。

1.密結合： DBオプションを変更しますか？さて、クライアント側のコードもすべて変更する必要があります。私を信じて。クライアント側でこれ以上の問題は必要ありません。

2. TMIセキュリティの問題：ものがどのように機能するかについてあまりにも多くを明らかにします。Authは依然として障害になる可能性がありますが、サーバー側で何が起こっているかを正確に把握していれば、悪用を見つけることは非常に簡単です。

非常に薄い中間層の方が良い方法かもしれません。

javascriptが唯一のデータベースアクセスレイヤーである場合、javascriptが無効になっている（またはデバイスのブラウザーでサポートされていない）場合、クライアントはWebアプリを使用できません。