在Sitecore中使用安全性时，您可以使用两个主要应用程序：安全编辑器和Access Viewer。从表面上看，这些工具看起来很相似，但它们扮演着截然不同的角色。让我们回顾一下每个应用程序以及它们的利用方式。
如果您还没有，请参阅Sitecore安全性第1部分：自定义角色和权限，以获取内容作者编辑内容所需权限的概述。
安全编辑器
Sitecore的安全编辑器用于通过导航Sitecore内容树为Sitecore项目分配权限。下面是主安全编辑器界面的屏幕截图。
使用Sitecore的安全编辑器有几种方法可以保护内容：
- 使用功能区中的角色和用户选择器，您可以识别要保护的角色或用户，然后直接单击网格以应用权限
正如您在屏幕截图中看到的，展开内容树将允许您查看权限的位置在网格中明确分配给选定的角色或用户。 - 如果双击左侧内容树中的项目，将打开一个安全对话框。此对话框允许您编辑或查看分配给项目的所有显式权限，而不仅仅是分配给所选角色或用户的权限。
注意：作为一个经常使用的功能点，您还可以通过Content Editor界面的“ 安全”功能区中的“ 分配”按钮访问此相同的对话框（假设您具有查看它的相应权限）。
Sitecore的安全编辑器只是图片的一部分，它允许您分配权限，并显示权限显式分配的位置。为了完成图片，我们需要一种机制来查看这些显式权限是如何实际显示的。这是Sitecore的Access Viewer桥接的差距。
Access Viewer
Sitecore的Access查看器是您的安全实现的只读视图。它用于通过在Sitecore内容树中显示所选用户或角色的安全权限来查看安全实现的表现方式。其主要目的是：
- 确认您的安全权限表现为预期;
- 如果您的权限未按预期工作，请解决用户或角色访问问题。
以下是Access Viewer主界面的屏幕截图。
在屏幕截图中，您可以看到sitecore \ ContentAuthor用户具有读取访问权限，同时已将写入/重命名/创建/删除授予主节点及其子节点，从而显示网格中显示的所有项目。值得注意的是，与安全编辑器不同，Access Viewer网格显示了角色成员身份和显式权限组合所实现的所有选定角色/用户权限的高潮。
为什么这很重要？由于用户很少属于单个角色，因此如果一个角色对另一个角色产生负面影响，我们必须能够确定权限问题的根本原因。因此，Access Viewer成为允许您在出现权限问题时进行诊断的工具。
要更深入地了解这一点，如果您有兴趣了解用户如何获得某个隐式或显式许可（或者就此而言，被拒绝某个权限），您可以直接单击权限本身，右侧轨道将填充额外的取证信息。举例来说，如果你有兴趣在如何Sitecore的\ ContentAuthor用户继承写到接入家庭节点，只需写权限在网格中单击，您将看到正确的轨道透露更多的信息：
在此示例中，您可以看到右栏中的文本指出写访问是通过显式项获得的：对sitecore \ Author角色的写访问权限，sitecore \ ContentAuthor是其成员的角色。声明下方的图像强化了此声明，该声明显示sitecore \ Author角色已在主节点上被授予显式写入权限。
相反，通过查看Home节点的Administer权限（尚未授予ContentAuthor用户的权限），Access Viewer报告用户没有此权限，因为它未被授予显式权限，也不属于授予这些权限的角色。
到目前为止，我们一直在审查不在工作流程中的项目。如果您已阅读我关于内容作者编辑权限的文章，您将了解工作流权限也会影响内容作者编辑内容的能力。
要了解这是如何在Access Viewer中显示的，让我们使用Sitecore的示例工作流程。我们将授予对ContentAuthor用户的工作流的草稿状态的工作流状态写入权限，但保留用户对等待批准状态没有权限。
当Home节点处于Draft状态时，Access Viewer现在会在您审核特定权限时显示有关工作流的其他信息：
在这种情况下，ContentAuthor用户可以编辑该项目，因为他们有足够的项目和工作流权限来执行此操作。
但是，如果我们现在将Home节点移动到Awaiting Approval状态，则Access Viewer信息会更改：
安全声明指出它们没有workflowState：write访问权限，随后，您无法编辑该项目。
结论
如您所见，如果您要在Sitecore中使用安全性，则需要熟悉这两个工具，因为它们可以一起工作，以便您分配安全权限并对其进行故障排除。
扫一扫
1241
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
