0

我们目前使用的通用报告将被多个用户组以不同的方式使用。我们通过创建具有不同隐藏参数设置的链接报告（例如“显示列 x”、“启用功能 y”）来实现这一点。其他报告也需要这些设置（参数），因此我们使用Go to ... Action.

为了创建我们所追求的外观和感觉，我们还传递了一些额外的参数，HTML Viewer commands例如Report Server commands( &rc:Parameters=Falsereference )。

不幸的是，这给我们留下了唯一的选择Go to URL，因为微软还没有为Go to Report. 这意味着我们必须在 URL 中传递我们的设置（隐藏参数）。这会导致安全问题，例如：&PARAMETER_ENABLE_FEATURE_Y=False.

用户可能会注意到 URL 中的此参数，因此可以通过将 URL 编辑为 来启用此功能&PARAMETER_ENABLE_FEATURE_Y=True。

所以我的问题是：如何使用ActioninReporting Services同时防止用户编辑我们的敏感参数并同时能够使用HTML Viewer commandsand Report Server commands？

4

1 回答 1

1

如果您绝对必须使用基于 URL 的参数，那么您将永远无法获得完全的安全性。

通过 URL 导航时，隐藏参数值而不对其进行硬编码的唯一方法是使它们成为数据驱动的。但是，在您的场景中，这不是 100% 安全的，因为您仍然需要传递填充数据驱动参数的值。

这种程度的混淆可能就足够了，可以通过整理每个参数组合的列表或仅列出您需要的参数组合并为其分配一个可以在数据集中调用的 ID 来实现。如果您的用户感到好奇并且维护起来可能很麻烦，这显然仍然可以由您的用户更改。

我想说您唯一的其他选择是通过为您的报告提供“登录页面”并在 iframe 中显示所有内容来完全隐藏 URL 栏。此框架可以在您的 javascript 链接中定位Go To URL：

="javascript:void(window.open('URL to open','iFrame Name'))"

如果可以的话，我建议您将用户分组到 Active Directory 安全组中，然后维护每个组的权限和自定义集合。然后，您可以使用类似于此处答案的自定义代码检查用户属于哪些组，并相应地返回所需的参数值。

假设您在所有报告中推出了相同的参数结构，那么这样做还可以让您维护哪些组可以从一个中心位置看到什么。

于 2016-12-20T10:18:29.227 回答