👨🏾‍🤝‍👨🏼 🛌🏽 🍍 Meteorだけでなくセキュリティについて（パート1） 🔄 📕 👨‍💻

Meteorフレームワークアプリケーションを開発するためのセキュリティを提供するために設計された多くのトリックとツールがあります。第1部では、コードのサーバー側の非表示、自動公開/安全でないパッケージ、公開時のコレクションフィールドの非表示、およびMeteor.usersコレクション内のビルトインアカウントシステムの詳細について説明します。 2番目 -クライアントに発行されたloginTokenについて、クライアント、信頼できるコードと信頼できないコード、サーバーメソッド、HTTPS、force-sslパッケージおよびbrowser-policyパッケージ（コンテンツセキュリティポリシーとX-Frame-Options）でデータベースを変更するときのルールを許可/拒否します。組み込みのデータ検証メカニズム（check（）関数およびaudit-arguments-checkパッケージ）。

以下に説明するすべては、MeteoriteがインストールされているMeteor 0.7.0.1の現在のバージョンに適用されます。ちなみに、この記事の例が新しいバージョンのMeteorで機能しない場合、Meteoriteを使用すると、起動時に--releaseスイッチを指定してこの記事の例を見ることができます。

$ mrt --release 0.7.0.1

コードの裏を隠す

おそらく、最も単純なものから始めましょう-コードのクライアント部分とサーバー部分の多様性。 Meteorではクライアントとサーバー間でコードを共有できますが、本当に必要な場合にのみ共有するのが理にかなっています。プロジェクト自体の構造化は、ボリュームが大きくなるにつれて何らかの方法で必要になり、クライアントに転送されるデータ量が減少することに加えて、サーバー側のコードを隠すことができます。

サブディレクトリサーバー、クライアント、クライアント/互換性、パブリック、プライベート、ライブラリ、テスト（およびメイン。*ファイル）は、特別な方法で処理されます。これについては、ドキュメントdocs.meteor.com/#structuringyourappで詳細に説明されています。サーバー上でのみ実行されるコードの場合、サーバーディレクトリが対象となり、ファイルはクライアントに転送されません。同様に、クライアントディレクトリ内のファイルのコードはサーバーにアップロードされません。

コレクション宣言などの一部のコードは、クライアントとサーバーの両方で使用できる必要があります。このようなコードは、予約以外の名前でサブディレクトリに配置できます（libに配置することもできます。違いは、このディレクトリからのファイルが他よりも早くダウンロードされることです）。

この例の一部として、collectionsサブディレクトリにコレクション宣言を配置します。

新しいアプリケーションを作成しましょう：

 $ mrt create littlesec

そして、自動的に作成されたファイルを削除します。

 $ cd littlesec $ rm littlesec.*

サブディレクトリサーバー、クライアント、コレクションを作成します。コレクションで、テストコレクションの宣言とともにファイルtest.jsを追加します。

 Test = new Meteor.Collection('test');

実際、プロジェクトはすでに起動できます：

 $ mrt

ブラウザで開きます： localhost ：3000

空白のページのみが表示されますが、テストオブジェクトは空ではありますが、コンソールから既に利用可能です。

 > Test.find().count() 0

home.htmlファイルをクライアントのサブディレクトリに追加します。

 <head> <title>littlesec</title> </head> <body> {{> home}} </body> <template name="home"> {{#each test}} <li> <ul>_id:'{{_id}}' name:'{{name}}' value:'{{value}}'</ul> </li> {{else}} <p>Collection Test is empty</p> {{/each}} </template>

そして、home.js：

 Template.home.test = function() { return Test.find({}); }

サーバーのサブディレクトリ-startup.jsファイル：

  Meteor.startup(function(){ if (!Test.find({}).count()) { var testValues = [ {name: 'First', value: 1}, {name: 'Second', value: 2}, {name: 'Third', value: 3} ]; testValues.forEach( function(testValue) { Test.insert(testValue); }); } });

これで、テストコレクションはクライアントとサーバーの両方で使用でき、サーバーコードはクライアントに送信されません。 _idフィールドは、新しいレコードが挿入されたときに自動的に生成されるデータベース識別子です。

現時点では、コレクションは読み取りと書き込みの両方で完全に誰でも利用できます。これはコンソールから確認できます。

 > Test.findOne({})

そして：

 > Test.insert({name: 'Fourth', value: 4})

自動公開/安全でないパッケージを削除する

作成時にプロジェクトにデフォルトで接続された自動公開および安全でないパッケージのおかげで、発表したコレクションに完全にアクセスできました。最初のものはサーバー上に存在するすべてのコレクションを「公開」し、2番目のものはそれらを変更するための完全な権限を与えます。これにより、Meteorとラピッドプロトタイピングの理解が大幅に促進されますが、もちろん実際の生活では受け入れられません。したがって、

 $ mrt remove autopublish $ mrt remove insecure

ブラウザのテストオブジェクトは引き続き使用できますが、データはありません。

 > Test.find().count() 0

これで、自動発行なしの通常モードでは、クライアントはサーバーデータにアクセスでき、サーバーはそれを発行し、クライアントはサブスクライブする必要があります。

コレクションの公開をserver / startup.jsファイルに追加します（Meteor.startup（）によって追加された関数の外側と内部の両方に配置できます。違いは、公開が作成されたときです-公開されたコレクションがこの時点で既に存在することが重要です）：

 Meteor.publish('test', function() { return Test.find(); } );

自動公開パッケージがまだプロジェクトに接続されている間にコレクションが公開されると、Meteorの開始時にこれに関する警告が表示されます。

 I20140131-11:36:07.343(4)? ** You've set up some data subscriptions with Meteor.publish(), but I20140131-11:36:07.388(4)? ** you still have autopublish turned on. <..>

適切なサブスクリプションをclient / home.jsファイルに追加します。

  Meteor.subscribe('test');

これで、データがブラウザに再び表示されますが、それを変更する権限はありません。

 > Test.insert({name: 'Fifth', value: 5}) "BDgB258TovmqS7YbY" insert failed: Access denied

レコードが最初にローカルコレクションに挿入され、その識別子が返され（「BDgB258TovmqS7YbY」）、このレコードがブラウザに表示され、サーバーからエラー通知が受信され、ローカルコレクションへの挿入がロールバックされることに注意してください。ブラウザでの表示は遅延補正メカニズムによるものであり、許可/拒否ルールのチェックによりエラーが表示されます（それらについては少し後で）。安全でないパッケージがない場合、デフォルトの変更は禁止されています。

公開時にフィールドを非表示

コレクションを完全に公開する必要はありません。これまで、サーバーコレクションのすべてのフィールドが表示されました。たとえば、_idフィールドを非表示にできます。これにより、クライアント側でデータを変更するためのレコードIDを指定する必要があるため（IDによるデータ変更の制限も参照）、これがMeteorコレクションに実装されるなど、データを操作する機能が制限されます。ユーザー（以下を参照）：

 Meteor.publish('test', function() { var projection = {_id: 0, value: 1}; return Test.find({}, {fields: projection} ); // return Test.find(); } );

残念ながら、_idフィールドはこの方法で非表示にすることはできません。おそらく、サーバーとローカルコレクション間の対応を確立するために使用されます。現在のバージョンでは、これによりエラーが発生し、以前は空のコレクションが返されていました。

もちろん、フィールドを非表示にすると、転送されるデータの量にもプラスの効果があります。

流星口座システム

上記のすべては、許可されていないユーザーに適用されます。また、ユーザーが承認された場合、どのような機会が表示されますか？

Meteorアカウントシステムのプロジェクトサポートに追加します。

 $ mrt add accounts-base $ mrt add accounts-ui $ mrt add accounts-google

accounts-googleに加えて、Facebook、Twitter、Githubなど、多数の承認プロバイダー向けの公式パッケージがあります。非公式パッケージは、Vkontakteなどの他のプロバイダーもサポートしています。

home.htmlで既製のユーザー認証ボタンテンプレートを使用します。

 {{loginButtons}}

ユーザー情報を表示するcurrentUser：

 {{currentUser._id}} {{currentUser.profile.name}}

そして、最初にボタンをクリックしたときに表示されるステップバイステップの手順を使用して、アプリケーションをGoogleに登録すると、すぐにユーザーを承認できます。

Facebookをサポートするパッケージを追加します。

 $ mrt add accounts-facebook

次に、2番目のユーザーを登録します。

アカウントはMeteor.usersコレクションに保存されますが、ブラウザでアクセスすると、すでに2人の登録ユーザーがいるにもかかわらず、1つのドキュメントのみが表示されます。

 > Meteor.users.find().count() 1

実際には、デフォルトで（自動発行パッケージが無効になっている場合-すべてが少し複雑になります）、クライアントはこのコレクション内の自分のドキュメントのフィールドの一部のみにアクセスできます。

 > Meteor.users.findOne()) {"_id":"8fLXBYpNGLqDwAahg","profile":{"name":"< >"}}

同じドキュメントはMeteor.user変数を介して利用でき、その識別子はMeteor.userId（）です。

 > Meteor.user() {"_id":"8fLXBYpNGLqDwAahg","profile":{"name":"< >"}}

対応する関数（ヘルパー）Handlebars currentUserがあり、現在のユーザーに関する情報を表示します。

accounts-baseパッケージのソースコードを見ると、Meteor.usersコレクションがサーバー上に次のように作成されています。

 Meteor.users = new Meteor.Collection("users", {_preventAutopublish: true});

そして、このように公開されました：

 // Publish the current user's record to the client. Meteor.publish(null, function() { if (this.userId) { return Meteor.users.find( {_id: this.userId}, {fields: {profile: 1, username: 1, emails: 1}}); } else { return null; } }, /*suppress autopublish warning*/{is_auto: true});

ユーザーが承認されている場合、this.userIdには識別子が含まれます。この識別子により、プロファイルサブドキュメントがデータベース、ユーザー名フィールド、および電子メールサブドキュメントから返されます（最後の2つはデフォルトでは入力されません）。それ以外の場合、データは公開されません。これは、デフォルトでは、フィールドの一部のみとデータベースからの自分のドキュメントのみが許可ユーザーにアクセス可能であることを意味します。

ソーシャルネットワークからユーザーのGoogle画像へのリンクはサブドキュメントservices.google.pictureに保存され、services.facebook.idという識別子を使用してFacebookから画像にアクセスできます。それらにアクセスするには、たとえば次のように追加で公開する必要があります（サーバーに追加/ startup.js）：

 Meteor.publish(null, function() { if (this.userId) { var projection = { 'services.google.picture': 1, 'services.facebook.id': 1, 'services.vk.photo': 1 }; return Meteor.users.find( { _id: this.userId }, { fields: projection } ); } else { return null; } });

そして、画像へのリンクはhome.htmlにあります。

  {{#if currentUser.services.facebook}} <img src="http://graph.facebook.com/{{currentUser.services.facebook.id}}/picture/?type=square"> <!-- small || normal || large || square --> {{else}}{{#if currentUser.services.google}} <img src={{currentUser.services.google.picture}}> {{else}}{{#if currentUser.services.vk}} <img src={{currentUser.services.vk.photo}}> {{/if}}{{/if}}{{/if}}

選択したフィールドがクライアントで使用できるようになりました。

 > Meteor.users.findOne() { "_id":"8fLXBYpNGLqDwAahg", "profile": { "name":"< >" }, "services": { "facebook": { "id": "<  Facebook>" } } }

フィールドを明示的に指定する代わりに、projection = {}を設定してユーザードキュメント全体を公開するか、projection = {services：1}を設定してサービスサブドキュメントを公開できます。ただし、この場合、クライアントは明らかにaccessTokenやloginTokensなどの追加データを受け取ります。

他のユーザーに関する情報を表示する必要がある場合、コレクション内のすべてのドキュメントの選択したフィールドを公開できます。たとえば、既存の公開にもう1つ追加できます。

 Meteor.publish(null, function() { var projection = { 'profile.name': 1 }; return Meteor.users.find( { }, { fields: projection } ); });

その結果、すべてのパブリケーションが統合され、現在では、許可されていないパブリケーションを含むすべてのユーザーにすべての登録ユーザーの名前が表示され、現在のユーザーにはドキュメントの追加フィールドが表示されます。

 Meteor.users.find().fetch() [ { "_id":"8fLXBYpNGLqDwAahg", "profile": { "name":"< >" } }, { "_id":"kL7Fkuk29ci4vz8q4", "profile": { "name":"< >" }, "services": { "google":{ "picture":"<  >" } } } ]

Meteorだけでなくセキュリティについて（パート1）

コードの裏を隠す

自動公開/安全でないパッケージを削除する (adsbygoogle = window.adsbygoogle || []).push({});

公開時にフィールドを非表示 (adsbygoogle = window.adsbygoogle || []).push({});

流星口座システム

More articles:

自動公開/安全でないパッケージを削除する

公開時にフィールドを非表示