例如，我有文檔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）搜索，她去搜索，如：
q=mainquery
&fq=access_roles:user_jane
&fq=access_roles:manager_vienna
&facet=on
&facet.field=access_roles
其獲取包含user_janeORmanager_vienna在access_roles所有文件; Doc1和Doc2。
當Bob，（user_bob），一個特殊的團隊的一員（specia_team）搜索，
q=mainquery
&fq=access_roles:user_bob
&fq=access_roles:special_team
&facet=on
&facet.field=access_roles
這對於他取Doc2。改編自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 2012-02-14 07:14:20
我覺得我的做法是類似於@ 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 2012-02-14 07:13:45
我同意Haldrich98。要閱讀他的方法的基礎，請參閱RBAC：http://en.wikipedia.org/wiki/Role-based_access_control 並且，基於RBAC方法，請參閱Tie-RBAC：將RBAC應用於社交網絡（http：///w2spconf.com/2011/papers/rbacSocialNet.pdf）關於@manny分享問題 – 2012-02-20 01:57:54
請記住，solr是基於純文本的搜索引擎，索引系統，爲了便於快速搜索，您不應該期望它具有RDMS樣式功能。 solr不提供索引文檔的安全性，如果需要，您必須編寫這樣的實現。在這種情況下，你有兩種選擇。 1）只需將文檔索引到solr並將授權詳細信息保存到RDBMS.Now查詢solr以進行搜索並收集返回的結果。現在，向sol返回由solr返回的doc id的另一個查詢，以查看用戶是否有權訪問它們或者不是。過濾那些用戶無法訪問的文檔。完成！但不是真的，你的問題只是從這裏開始。假設，如果solr返回的所有結果都被過濾出來了？ （假設您一次不訪問所有文檔，意味着您只從solr結果集中檢索前1000個結果，否則無法快速搜索）您必須再次查詢solr以獲取下一堆結果集，並且必須迭代這些步驟直到您獲得足夠的結果來顯示。 2）第二種方法是索引授權元數據以及solr中的文檔。正如aitchnyu所解釋的那樣。但要回答您向外部用戶分享文檔的查詢，以及用戶組和角色詳細信息，請將這些外部用戶用戶標識到access_roles字段中，或者您也可以將另一個字段添加到模式「access_user」中。現在您可以修改外部用戶共享的搜索查詢，以將access_user字段添加到您的過濾器查詢中。 如
q=mainquery
&fq=access_roles:group_1
&fq=access_user:externaluserid
現在最重要的事情，更新的索引documents.Well其關閉過程繁瑣的任務，但精心的設計和異步處理與solrs沿部分文件更新功能（Solr的4.0 =>），你可以用solr實現合理的TPS。如果您使用的是solr < 4。0你可以有單獨的系統來進行搜索和更新，並且充分利用負載平衡器和主從複製策略，你將會對你的臉微笑！
您可以使用Solr的PostFilter實現您的安全模型。欲瞭解更多信息，請參閱http://searchhub.org/2012/02/22/custom-security-filtering-in-solr/
注意：您應該緩存您的訪問權限，否則性能將是可怕的。
這種方法意味着我必須重新編制索引，當我對訪問角色進行更改時，權限是？任何方法來避免這種情況？ – Manny 2012-02-10 09:54:42
如果您希望更改**文檔**的訪問角色，可以訪問文檔的訪問角色是什麼類型，您必須重新編制索引。這是**查詢**，每個用戶都有所不同。 – aitchnyu 2012-02-10 16:12:55
編輯包括 – aitchnyu 2012-02-10 16:34:00