8

インデックス作成エンジン、特にApacheLuceneSolrを調べています。私たちはそれを検索に使用する用意がありますが、フレームワーク検索によって解決される問題の1つは、行レベルのアクセスです。

Solrは、箱から出してすぐにレコードアクセスを提供しません。

<...> Solrは、ドキュメントレベルでも通信レベルでもセキュリティに関心がありません。

そして、ドキュメントレベルのセキュリティに関するセクション：http ：//wiki.apache.org/solr/SolrSecurity#Document_Level_Security

いくつかの提案があります-マニフォールドCF（非常に文書化されておらず、非常にプレベータ段階にあるようです）を使用するか、独自のリクエストハンドラ/検索コンポーネント（その部分はスタブとしてマークされています）を作成します-後者はパフォーマンスへの大きな影響。

ですから、この分野ではあまり行われていないと思います。

最近リリースされたSolrの4.0バージョンでは、2つのインデックス付きエンティティの結合が導入されました。私たちのフレームワークは、ユーザーがレコードにアクセスできるかどうかを知るために結合も行うため、結合は良い考えのように思えるかもしれません。ここでの問題は、内部結合を行う場合と、スコープ内の外部（楽観的（禁止されていないものすべてが許可される）または悲観的（明示的に許可されているもののみが禁止される）セキュリティ設定に応じて）を行う場合があることです。

私たちの構造がどのように見えるかをよりよく理解するために：

ドキュメント

DocumentNr | Name
------------------
1          | Foo
2          | Bar

DocumentRecordAccess

DocumentNr | UserNr | AllowRead | AllowUpdate | AllowDelete
------------------------------------------------------------
1          | 1      | 1         | 1           | 0

したがって、たとえば、悲観的なセキュリティ設定でドキュメントに対して生成されたクエリは次のようになります。

SELECT * FROM Documents AS d 
INNER JOIN DocumentRecordAccess AS dra ON dra.DocumentNr=d.DocumentNr AND dra.AllowRead=1 AND dra.UserNr=1

これはfooのみを返し、barは返しません。そして楽観的な設定で：

SELECT * FROM Documents AS d 
LEFT JOIN DocumentRecordAccess AS dra ON dra.DocumentNr=d.DocumentNr AND dra.AllowRead=1 AND dra.UserNr=1

両方を返す-FooとBar。

私の質問に戻ります-多分誰かがすでにこれをしていて、彼らの洞察と経験を共有することができますか？

4

2 に答える 2

7

ここには簡単な解決策はありません。ACLを検索と連携させるには、何かを犠牲にする必要があります。

  1. コーパスのサイズが小さい場合（最大10Kのドキュメントと言います）、禁止された（または許可された、どちらか冗長でない）ドキュメントのキャッシュビットセットを作成し、関連するフィルタークエリを送信できます(+*:* -DocumentNr:1 ... -DocumentNr:X)。言うまでもなく、これは拡張性がありません。大きなクエリを送信すると検索が少し遅くなりますが、これは管理可能です（もちろんある程度まで）。クエリの解析は安価です。

  2. どういうわけかこれらのドキュメントをグループ化し、ドキュメントグループにACLを適用できる場合、これによりクエリの長​​さを短縮でき、上記のアプローチは完全に適合します。fqこれは、私たちが使用しているものとほぼ同じです。私たちのソリューションは、分類法を実装し、クエリを介して分類法のアクセス許可を取得します。

  3. 全体的な結果セットの数を表示する必要がない場合は、クエリを実行して、クライアント側で結果セットをフィルタリングできます。繰り返しますが、完璧ではありません。

  4. 次のように、データ構造を非正規化し、両方のテーブルを1つのドキュメントにフラット化して保存することもできます。

    DocumentNr：1
    名前：Foo
    Allowed_users：u1、u2、u3（またはForbidden_​​users：...）

    残りは、クエリでユーザーIDを送信するのと同じくらい簡単です。

    上記は、ACLがめったに変更されない場合にのみ実行可能であり、変更されたときにコーパス全体のインデックスを再作成する余裕があります。

  5. BitSetデータベースから取得したユーザー（グループ？）によって許可または禁止されたドキュメントをキャッシュするカスタムクエリフィルターを作成できます。これには、Solr WebアプリケーションにDBアクセスを提供するだけでなく、Solrに付属する.warを拡張/再パッケージ化する必要があります。これは比較的簡単ですが、難しい部分はキャッシュの無効化です。メインアプリは、ACLデータが変更されたときにSolrアプリに何らかの方法で通知する必要があります。

Solrとアプリを同じJVMに配置し、 javabinドライバーを使用できる場合は、オプション1と2の方がおそらくより合理的です。

コーパス/ACLの詳細を知らずにこれ以上アドバイスするのは難しいです。

于 2012-12-13T22:22:33.967 に答える
3

私はmindasに同意します。彼が提案したこと（sol-4）、私は同じ方法でソリューションを実装しましたが、違いは、ACLのタイプがほとんどないことです。ユーザーグループレベル、ユーザーレベル、さらにはドキュメントレベル（プライベートアクセス）。

ソリューションは正常に機能しています。しかし、私の場合の主な懸念は、ACLが頻繁に変更され、インデックスで更新する必要があることです。つまり、検索パフォーマンスも影響を受けないはずです。

負荷分散とクラスターへのノードの追加でこれを管理しようとしています。

mindas、unicronこれについて考えていただけますか？

于 2012-12-20T13:08:08.800 に答える