索引 Sitecore 项目的安全性并限制返回的搜索结果 [英] Indexing Sitecore Item security and restricting returned search results

问题描述

我定义了多个角色，每个角色对内容和媒体项目都有不同的限制，我想根据当前登录用户的访问权限限制返回的搜索结果，而不是显示结果和用户然后显示拒绝访问"页面.某些内容显然可以被外联网匿名访问，因此无论如何都应该为所有用户返回这些内容.

I have several roles defined, each with different restrictions to content and media items and I would like to restrict the search results that are returned based on the access rights of the currently logged in user, rather than displaying the result and the user then presented with an "Access Denied" page. Some content will obviously be accessible to extranetanonymous so they should be returned for all users regardless.

安全性遵循标准的Sitecore 实践 因此将使用角色继承(角色内的角色)，因此也需要考虑到这一点.

The security follows the standard Sitecore practices so Role inheritance (roles within roles) will be used, so it will need to take this into account also.

我在 高级数据库爬虫模块中看不到任何内容会有所帮助，我已经浏览了 Sitecore 搜索和索引指南 (6.6 版 和 版本 7)，但找不到有关索引应用于项目的安全性的任何信息.以下文章有一些建议:

I couldn't see anything in the Advanced Database Crawler module that would help and I've looked through the Sitecore Search and Indexing Guide (version 6.6 and version 7) but couldn't find any information about indexing the security applied to items. The following articles have some suggestions:

• 如何我可以在 Sitecore 中设置一个 Lucene 索引来正确处理安全问题吗?

这感觉很脏"，并且有可能出现性能问题，尤其是在返回大量项目时.此外，(见评论)分页结果的问题.

This feels "dirty" and has the potential for performance issues, particularly when there are a large number of items returned. Also, (see in the comments) the issue with paging results.

• 安全(又名权限)和 Lucene - 如何?应该做吗?

以上看起来更现实，并且会根据索引的安全角色过滤结果，显然需要扩展角色以处理角色内的角色.我在这里担心的是，当我们特别需要拒绝/限制某些角色对内容项的访问时，我们需要处理被拒绝的权限(我知道这不是推荐的做法，但有一个非常具体的需要总是拒绝).

The above looks more realistic, and would filter out the results based on indexed security roles, there would obviously be a need to expand the roles to handle roles within roles. My concern here would be that we would need to handle denied permissions, when we specifically need to deny/restrict access for certain roles to content items (I know this is not recommended practice, but there is a very specific need to always deny).

我目前正处于规划阶段，所以随着今天 Sitecore 7 的发布，如果这让生活更轻松，也有可能使用更新的 Lucene 库和/或 SOLR - 当然假设某些模块比如营销人员的WebForms和Email Campaign Manager 更新时间过长.

I'm at the planning stage at the moment so with the release of Sitecore 7 today there is also the possibility to use the updated Lucene libraries and/or SOLR if that makes life easier - assuming of course that some of the modules like WebForms for Marketers and Email Campaign Manager are updated before too long.

考虑到安全性，人们使用哪些解决方案返回搜索结果?除了上面的链接问题，还有其他选择吗?也许我可以利用 Sitecore 7 中的某些东西，更新的 Lucene 库或 SOLR?

What are the solutions that people are using for returning search results taking into account security? Any alternatives than the linked questions above? Maybe something in Sitecore 7 that I can leverage, the updated Lucene libraries or SOLR?

如果可能，我更愿意保留所有这些开箱即用"的 Sitecore，并且不使用其他第三方搜索产品.

I'd prefer to keep this all "out of the box" Sitecore and not use other third party search products if at all possible.

推荐答案

Klaus 建议的一个小替代方案:

A slight alternative to the suggestion from Klaus:

在 Sitecore.ContentSeach.config 中，您会找到一个名为 contentSearch.getGlobalSearchFilters

In Sitecore.ContentSeach.config you'll find a pipeline called contentSearch.getGlobalSearchFilters

添加到此管道的处理器将应用于任何查询，因此如果我们添加一个基于角色应用过滤器的处理器，我们就很好.

Processors added to this pipeline will be applied to any query, so if we drop in one that applies a filter based on roles we're good.

首先，我们希望在索引配置中添加一个计算字段:

To start, we want a computed field added to our index configuration:

<fields hint="raw:AddComputedIndexField">
   <field fieldName="read_roles"           returnType="stringCollection">Sitecore.ContentSearch.ComputedFields.ReadItemRoles,Sitecore.ContentSearch</field>
</fields>

注意 存储的类型是字符串的集合.我们将使用它来索引所有可以读取项目的角色名称.

NOTE the stored type is a collection of strings. We'll use it to index all the names of roles that can read an item.

1. 我们有一个抽象基类来处理项目安全细节的提取

1. We have a base abstract class to handle the extraction of item security details

public abstract class ItemPermissions: IComputedIndexField
{
    public string FieldName { get; set; }
    public string ReturnType { get; set; }

    public object ComputeFieldValue(IIndexable indexable)
    {
        var indexableItem = indexable as SitecoreIndexableItem;
        if (indexableItem == null) return null;

        var security = indexableItem.Item.Security;

        return GetPermissibles(security);
    }

    protected abstract object GetPermissibles(ItemSecurity security);
}

我们用抽象方法来实现上面的

We implement the above with the abstracted method

public class ReadItemRoles : ItemPermissions
{
    protected override object GetPermissibles(ItemSecurity security)
    {
        var roles = RolesInRolesManager.GetAllRoles();
        return roles.Where(security.CanRead).Select(r => r.Name);
    }
}

注意 这里显然会对性能产生影响，这会降低您的索引速度.为了减少影响，仅将计算字段添加到包含安全内容的索引的索引配置中.例如.如果您的网页内容仅供匿名用户访问，则不会带来任何好处.

NOTE There's obviously a performance impact here, this will reduce your indexing speed. To reduce the impact, only add the the computed field to the index configuration for the index that contains secured content. E.g. If your web content is only accessed by the anonymous user it will add no benefit.

将条目添加到配置中

<contentSearch.getGlobalSearchFilters>
    <processor type="Sitecore.ContentSearch.Pipelines.GetGlobalFilters.ApplyGlobalReadRolesFilter, Sitecore.ContentSearch" />
  </contentSearch.getGlobalSearchFilters>

实施

实现管道过滤器来检查上下文用户的角色

Implementation

Implement the pipeline filter to check the roles of the context user

public class ApplyGlobalReadRolesFilter : GetGlobalFiltersProcessor
{
    public override void Process(GetGlobalFiltersArgs args)
    {
        var query = (IQueryable<SitecoreUISearchResultItem>)args.Query;

        var userRoles = Context.User.Roles.Select(r => r.Name.Replace(@"", @"\"));

        var predicate = PredicateBuilder.True<SitecoreUISearchResultItem>();
        predicate = userRoles.Aggregate(predicate, (current, role) => current.Or(i => i["read_roles"].Contains(role)));

        if(predicate.Body.NodeType != ExpressionType.Constant)
            args.Query = query.Filter(predicate);
    }
}

总结

1. 创建一个 ComputedField，返回给定访问权限的所有有效角色的列表
2. 将管道处理器应用于 contentSearch.getGlobalSearchFilters 以向每个搜索请求添加查询过滤器.
3. 使用 PredicateBuilder 类来确保角色名称被 OR 运算在一起

1. Create a ComputedField that returns a list of all valid roles for a given access right
2. Apply a pipeline processor to contentSearch.getGlobalSearchFilters to add a query filter to each search request.
3. Use the PredicateBuilder class to ensure the role names are OR'ed together

这里的最大好处是您可以在索引时进行命中，并且项目限制的处理是通过搜索查询正常处理的.无需担心构面编号或搜索计数不正确.

The big benefit here is that you take the hit at index time and the handling of item restriction is handled through a search query as normal. No need to worry about the facet numbers or search counts being incorrect.

您可以限制正在检查的角色来计算字段，并且可以改变管道过滤器的应用.您甚至可以去掉管道过滤器，并在需要时更新您的查询以进行过滤.

You can restrict the roles you are checking to compute the field and you can vary the application of the pipeline filter. You can even take out the pipeline filter and just update your queries to filter when you require it.

注意 此设置的最大问题是当安全限制更改时需要重新索引您的内容.如果您对用户本身应用安全限制，则必须包含额外的计算字段.

NOTE The biggest problem with this set up is the requirement to re-index your content when security restrictions change. Should you be applying security restrictions to users themselves, you'll have to include additional computed fields.

编辑 02/06/2013

我只是在一个项目中对此进行了修补，并意识到它正在对查询中的角色进行 AND 运算.如果用户分配了多个角色，则两个角色都必须声明对该项目的权限.我已经更新了管道处理器以使用 PredicateBuilder 类对角色进行 OR 运算.还添加了一项检查以确保谓词不是常量，这确保仅当我们有过滤器要应用时才会更新查询.

I was just tinkering with this in a project and realised that it was AND'ing the roles in the query. If a user had multiple roles assigned then both roles would have to have declared rights to the item. I've updated the pipeline processor to use the PredicateBuilder class to OR the roles. A check is also added to ensure the predicate is not a constant, this ensures the query is updated only if we have a filter to apply.

这篇关于索引 Sitecore 项目的安全性并限制返回的搜索结果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！