たとえば、ドキュメントA、B、Cがあります。ユーザー1はドキュメントA、Bのみを表示できます。ユーザー2はドキュメントCしか表示できません。メタデータでフィルタリングせずにSOLRでそれを行うには？メタデータフィルタを使用すると、アクセス権の変更があるたびに、インデックスを再作成する必要があります。SOLRアクセス権に応じたアクセス権/フィルタリング結果
[更新2/14/2012]残念ながら、クライアントのケースでは、変更が頻繁に行われます。データは機密情報であり、通常は内部ユーザーである所有者のみが管理します。特定のケースでは、それらのドキュメントを特定の外部ユーザーと共有し、それらのユーザーのアクセスレベルを指定できる必要があります。ほとんどの場合、これは暫定的な作業であり、事前には特定されていません。
アクセスロール（はい、複数形）をドキュメントのメタデータとして保存することをお勧めします。ここで必要なフィールドaccess_rolesは、ファセット可能な複数値の文字列フィールドです。
Doc1: access_roles:[user_jane, manager_vienna] // Jane and the Vienna branch manager may see it
Doc2: access_roles:[user_john, manager_vienna, special_team] // Jane, the Vienna branch manager and a member of special team may see it
文書を所有しているユーザーは、そのドキュメントのデフォルトアクセスの役割です。
文書のアクセスロールを変更するには、access_rolesを編集します。彼女はに属しジェーン検索、アクセスロールは、クエリの一部となります
。 Solrは、ユーザーのアクセスロールに一致するドキュメントのみを取得します。
ジェーン（user_jane）、ウィーン事務所（manager_vienna）検索のマネージャーは、彼女の検索は次のように行く：access_rolesでuser_janeORmanager_viennaが含まれているすべての文書を取得し
q=mainquery
&fq=access_roles:user_jane
&fq=access_roles:manager_vienna
&facet=on
&facet.field=access_roles
。 Doc1およびDoc2。
場合はボブ、（user_bob）、特別チームのメンバー（specia_team）を検索し、彼のためにDoc2をフェッチ
q=mainquery
&fq=access_roles:user_bob
&fq=access_roles:special_team
&facet=on
&facet.field=access_roles
。 http://wiki.apache.org/solr/SimpleFacetParameters#Multi-Select_Faceting_and_LocalParams
から適応
クエリ私はそれを認識していたSolrのためのメカニズムに組み込まれて何がありませんあなたは、メタデータに権利を維持することなく、文書へのアクセスを制御することができます。 aitchnyuで概説されているアプローチは、それを本当の役割レベルに保ち、ユーザー固有の権限を文書に割り当てないと妥当と思われます。こうすることで、ユーザーにロールを割り当てることができ、インデックス内のドキュメントを表示することができます。役割が変更されたときに文書を再索引付けする必要があることは許されますが、時間がかかると必要な役割の大半を特定して、頻繁に再索引付けする必要性を減らすことができればうれしく思います。
ドキュメントレベルのセキュリティパッチをチェックしたい場合があります。
https://issues.apache.org/jira/browse/SOLR-1872
https://issues.apache.org/jira/browse/SOLR-1834
本当に助けてくれてありがとう – Manny
私は私のアプローチは、@のaitchnyuの回答と同様であると思います。私はしかし、メタデータ内の個々のユーザーを使用しません。 各文書にグループを作成する場合は、セキュリティ理由のために頻繁に再索引付けする必要があります。与えられた文書については
、あなたはaccess_rolesれている場合があります。このようにGROUP_1、group_3
を、GROUP_1とgroup_3は常にドキュメントの権利を保有。ただし、各ユーザーのグループを変更して、それに応じてクエリを調整することもできます。
クエリが生成されると、クエリの一部としてユーザーのグループが常に渡されます。私はGROUP_1とGROUP_2に属している場合、私のクエリは次のようになります。
q=mainquery
&fq=access_roles:group_1
&fq=access_roles:group_2
グループは動的にクエリで生成されているので、私は単純にグループからユーザーを削除し、新しいクエリが発行されたとき、彼ら削除されたグループはクエリに含まれなくなります。だから、GROUP_1からユーザーを削除すると、新しい、このようなクエリを作成します。
q=mainquery
&fq=access_roles:group_2
グループ1を必要とするすべての文書は、もはやユーザーがアクセスできなくなります。
の変更は、ドキュメントを再インデックスする必要がないため、リアルタイムで行うことができます。セキュリティ上の理由から再インデックスする必要がある唯一の理由は、特定のグループがもはやドキュメントにアクセスできないと決めた場合です。
多くの現実のシナリオでは、これは比較的一般的ではありません。人事部の文書はいつでも人事部で利用できるようになるはずですが、特定のユーザーが必ずしも人事部グループの一部であるとは限りません。
希望に役立ちます。
私は文書Aを外部ユーザに共有し、文書Bを別の外部ユーザに共有する必要がある場合など。これは私たちの共通のケースです。 – Manny
私はHaldrich98に同意します。彼のアプローチの基盤を読むためにRBACを参照してください。http://en.wikipedia.org/wiki/Role-based_access_control そして、RBACのアプローチに基づいて、参照してくださいタイRBAC：ソーシャルネットワークへのRBACのアプリケーション（のhttp：/ /w2spconf.com/2011/papers/rbacSocialNet.pdf）@mannyの共有に関する質問 –
solrは高速検索を容易にするために、純粋なテキストベースの検索エンジンであることを覚えておいてください。RDMSスタイルの機能は期待できません。 solrは、索引付けされる文書のセキュリティを提供しません。必要に応じて、そのような実装を記述する必要があります。その場合、2つの選択肢があります。 1）文書をsolrに索引付けし、権限の詳細をRDBMSに保存します。検索のための今の検索ソルと戻り値を収集します。次に、solrによって返されたdoc idsのDBへの別の問合せを起動して、実行中のユーザーがアクセス権を持っていないドキュメントをフィルタリングします。完了しました。しかし実際には、あなたの問題はここから始まるだけです。答え、solrによって返されたすべての結果が除外されるとどうなりますか？ （一度にすべての文書にアクセスしていないと仮定すると、solrの結果セットからのみ上位1000個の結果を取得していることを意味します。そうでなければ、高速検索を行うことはできません）次の結果セットのためにsolrを再度照会し、これらの手順は、表示するのに十分な結果が得られるまで実行します。 2）これに対する2番目のアプローチは、aitchnyuが説明したように、solr.Sameのドキュメントとともに認可メタデータを索引付けすることです。しかし、外部ユーザーへの文書共有の照会には、ユーザーグループとロールの詳細とともに、 useridをaccess_rolesフィールドに追加するか、別のフィールドをスキーマ 'access_user'に追加するだけです。外部ユーザーの共有の検索クエリを変更して、access_userフィールドをフィルタクエリに含めることができます。 例えば今、最も重要なことは、インデックス化への更新は（Solrの4.0 =>）そのオフコース面倒な作業をdocuments.Wellが、慎重な設計と非同期処理とsolrs部分文書更新機能とともに
q=mainquery
&fq=access_roles:group_1
&fq=access_user:externaluserid
、あなたはsolrで合理的に良いTPSを達成することができます。 solrを使用している場合< 4。0では、検索と更新の両方に別々のシステムを持つことができ、ロードバランサとマスタースレーブレプリケーション戦略を十分に活用して、あなたの顔に笑顔を浮かべることができます！
SolrのPostFilterを使用してセキュリティモデルを実装できます。詳細についてはhttp://searchhub.org/2012/02/22/custom-security-filtering-in-solr/
を参照してください。注：あなたはおそらく、そうでない場合、パフォーマンスはひどいだろうあなたのアクセス権をキャッシュする必要があります。
このアプローチでは、アクセスロールに変更があったときに再インデックスする必要がありますか？これを避ける手段はありますか？ – Manny
**ドキュメント**のアクセスロールを変更する場合は、ドキュメントにアクセスできるアクセスロールの種類を変更する必要があります。各ユーザーごとに異なる**クエリ**です。 – aitchnyu
これを含むように編集 – aitchnyu