排查行和列安全
行和列安全 允许某些人仅访问部分数据。要实现行和列安全，Metabase 会运行一个查询，该查询根据用户权限来过滤行和/或从表中选择一部分列；然后，用户的查询将在初始查询的结果上运行（即，在安全的数据上运行）。
这些文章将帮助您了解行和列安全的工作原理
如果您有不同的数据访问问题，请参阅相关问题。
用户无法查看他们应该能够看到的表中的行
Metabase 是否正在按用户属性过滤行？
根本原因：行安全正在使用用户属性来过滤行。
采取的步骤
这是预期行为：使用用户属性过滤行是行安全的工作方式。但如果您不希望 Metabase 过滤这些行，您需要
- 移除行安全（这将授予有权访问该表的所有用户访问所有行的权限）。前往管理 > 权限，然后更改该表的访问级别。
- 将用户添加到具有该表不同权限的组（或创建一个组）。查看数据权限指南。
用户可以查看他们不应该看到的行
用户可能看到他们不应该看到的行有几个原因。
这些人是否也属于有权查看整个表的组？
根本原因：用户属于有权查看表的组，因此可以看到所有行，而不仅仅是受保护的行。
采取的步骤
对于所讨论的用户，请检查他们属于哪些组。是否有任何组可以访问您要保护的表？如果是，请将其从该组中移除。请记住，每个人都属于“所有用户”组；这就是为什么我们建议您撤销“所有用户”组的权限，并创建新组以选择性地将权限应用于您的数据源。
问题是否可通过静态嵌入或公共分享获得？
根本原因：问题是公开的。公共问题，即使是那些使用静态嵌入的问题，也无法被保护。如果某人在未登录 Metabase 的情况下查看问题，Metabase 就缺少用于过滤数据的用户属性或组信息，因此将显示所有结果。
采取的步骤:
当您保护数据时，应避免公共分享。请参阅公共分享。
问题是 SQL 编写的吗？
根本原因。您无法将行和列安全应用于具有 SQL 访问权限的用户。他们对数据库的访问权限与用于将 Metabase 连接到数据库的用户帐户相同。即使您在 Metabase 中隐藏了表，有 SQL 访问权限的用户仍然可以查询这些表。也就是说，您也无法将行和列安全应用于 SQL 问题。行和列安全仅适用于通过查询生成器构成的问题。
采取的步骤
-
不要尝试将行和列安全应用于用 SQL 编写的问题，因为您无法这样做。
-
如果您想保护行或列，请避免将用户添加到具有该表 SQL 访问权限的组（或任何其他更具权限的访问权限）。
-
如果您想给予他们 SQL 访问权限，但仍限制他们可以看到的内容，您需要设置数据库中的权限，并通过具有该限制性访问权限的用户帐户连接该数据库。您可以多次将同一个数据库连接到 Metabase，每次都具有不同的访问级别，并向不同的组公开不同的连接。
问题是否正在从非 SQL 数据源检索数据？
根本原因：行和列安全不支持非 SQL 数据库。
采取的步骤
您在这里几乎无能为力：如果您需要应用行和列安全，您不能使用这些数据库。
如果使用单点登录 (SSO)，用户属性是否正确？
根本原因：如果用户通过 SSO 登录，但预期的属性未被保存并可用，则行和列安全策略将拒绝访问。
采取的步骤:
我们关于SAML 身份验证和JWT 身份验证的文档解释了如何使用您的身份提供程序将用户属性传递给 Metabase，（用户属性）可用于应用行和列安全。
用户可以看到他们不应该看到的列
管理员是否忘记设置行和列安全？
根本原因：管理员在设置行和列安全时没有限制对底层表的访问。
采取的步骤:
- 进入管理面板 > 要保护的表的权限。
- 检查行和列安全是否已设置，并且用于创建表自定义视图的问题是否排除了您不希望用户看到的列。
用于设置行和列安全的问题是否包含这些列？
根本原因：用于应用行和列安全的问题包含他们不应该看到的列。
采取的步骤:
确保您使用的是 SQL 问题来应用行和列安全，并且没有包含您应该排除的列。
如果您使用查询生成器构建问题（即，使用简单或自定义问题），您可能会无意中引入其他列。您可以通过在 Notebook 编辑器中查看问题并单击查看 SQL 按钮来检查确切包含的列。但再说一遍：如果您使用 SQL 问题来应用行和列安全，这个问题就会消失。
用户是否在另一个具有不同表权限级别的组中？
根本原因：您已将行和列安全应用于表，但用户也属于具有更高表访问权限的组。如果用户属于多个组，他们将获得跨所有组的数据源的最宽松访问权限。
采取的步骤:
将用户从所有具有更高级别访问权限的受保护表的组中移除。如果他们需要那些其他组的某些权限，您将需要创建一个具有一组新权限的新组，该组仅将行和列安全应用于该表。
用户看不到他们应该能够看到的列
他们的组是否已将行和列安全应用于该表？
根本原因：他们只能访问应用了行和列安全且仅显示部分列的表。
采取的步骤:
将这些人添加到具有查看表权限的组（或创建一个新组）。
管理员是否隐藏了表中的字段？
根本原因：管理员隐藏了表中的字段。
采取的步骤
转到管理 >表元数据并找到该表。检查以确保您希望显示的字段没有被隐藏。
字段是否被重新映射以显示受限表中的信息？
根本原因：如果一个用户确实具有行和列安全权限的表有一个字段使用重新映射来显示用户无权访问的另一个表的信息，那么他们将无法看到该表。例如，如果您将 ID 字段重新映射为显示产品名称，但用户无权访问产品表，那么他们将无法看到该列。
采取的步骤
- 转到管理面板 > 相关字段的表元数据。
- 如果值是从受限表重新映射的，请更改它，以便 Metabase 使用表中原始值。有关更多信息，请参阅元数据编辑。
问题是否可通过静态嵌入获得？
根本原因：静态嵌入默认显示所有结果。虽然可以通过锁定参数来控制过滤，但静态嵌入仅取决于包含页生成的令牌，而不是用户是否登录到 Metabase。
采取的步骤:
由于有人必须登录才能让 Metabase 为该用户应用行安全，因此当您想要限制对表的行或列访问时，请避免使用静态嵌入。
用户看不到他们应该能够看到的**数据**
某人应该能够在查询中查看表中部分值，但被拒绝访问或得到一个空结果集，而本应有数据。
根本原因：管理员限制了对该表的访问。如果限制过于严格（例如，“无访问权限”），那么用户可能根本无法看到任何数据。
采取的步骤
- 通过进入管理面板并查看相关表的权限来检查组的访问级别。
- 如果用户不属于有权访问该表的组，请将其添加到具有访问权限的组，或创建一个具有该表访问权限的新组并将其添加到该新组。
无法看到受保护数据的用户是否属于多个组？
根本原因：我们只允许对每个表应用一次行和列安全：如果某人属于两个或多个具有不同权限的组，那么每个用于确定是否允许访问的规则都会很混乱。因此，我们只允许一个规则。
采取的步骤
管理员可以创建一个新组来精确捕获谁可以访问什么。
您有其他问题吗？
阅读其他版本的 Metabase 的文档。