索引 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'ed 在一起

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

我只是在一个项目中对此进行了修补，并意识到它是对查询中的角色进行与"运算.如果用户分配了多个角色，那么这两个角色都必须声明对该项目的权限.我已更新管道处理器以使用 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屋！