Meteorが、クライアントが永続層(MongoDB)にシームレスにアクセスできるようにするminiMongoドライバーを提供していることは誰もが知っています。
クライアントが永続APIにアクセスできる場合、どのようにしてアプリケーションを保護しますか?
Meteorが提供するセキュリティメカニズムとは何ですか?また、どのようなコンテキストで使用する必要がありますか?
meteorコマンドを使用してアプリを作成すると、デフォルトでアプリに次のパッケージが含まれます。
これらを組み合わせることで、各クライアントがサーバーのデータベースへの完全な読み取り/書き込みアクセス権を持つ効果を模倣します。これらは便利なプロトタイピングツール(開発目的のみ)ですが、通常、実稼働アプリケーションには適していません。本番リリースの準備ができたら、これらのパッケージを削除するだけです。
さらに追加するために、Meteorは認証を処理するためにFacebook / Twitter/およびMuchMoreパッケージをサポートしており、最もクールなのはAccounts-UIパッケージです。
コレクションのドキュメントには次のように書かれています。
現在、クライアントにはコレクションへの完全な書き込みアクセス権が付与されています。任意のMongo更新コマンドを実行できます。認証を構築すると、挿入、更新、削除へのクライアントの直接アクセスを制限できるようになります。バリデーターやその他のORMのような機能も検討しています。
許可されていない挿入/更新/削除APIを使用しないようにクライアントを制限することについて話している場合は、それが可能です。
https://github.com/meteor/meteor/tree/171816005fa2e263ba54d08d596e5b94dea47b0d/examples/todosで彼らのtodoアプリを参照してください
また、ログインと登録を可能にする組み込みのAUTHモジュールが追加されました。だから安全です。XSS、Valiations、クライアントヘッダーなどを処理している限り。
ただし、ノードにデプロイすることで、いつでもmeteorアプリを完全に機能するnodejsアプリケーションに変換できます。したがって、nodejsアプリケーションを保護する方法を知っていれば、meteorを保護できるはずです。
0.6.4の時点で、開発モード中、is_clientブロックとis_serverブロックはどちらもクライアントシステムに送信されます。開発モードをオフにしたときに、これらが分離されているかどうかはわかりません。
ただし、そうでない場合、ハッカーはif(Meteor.is_server)コードのブロックを確認することでシステムから洞察を得ることができる可能性があります。特に、現時点ではまだコレクションをクライアントとサーバー上の別々のファイルに分離できないことに気付いたので、これは特に懸念されます。
重要なのは、セキュリティ関連のコードをサーバー以外のディレクトリのis_serverブロックに配置しないことです(つまり、/serverの下にあることを確認してください)。
クライアントとサーバーのディレクトリでクライアントとサーバーのコレクションを分離できないことに気が狂っているかどうかを確認したかったのです。実際、これには問題はありません。
これが私のテストです。これは、正常に機能しているように見えるパブリッシュ/サブスクライブモデルの簡単な例です。 http://goo.gl/E1c56