Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
# Sandboxing
[Sandboxing data][sandboxing-your-data] gives some people access to only a subset of the data. (The term comes from the practice of putting children in a sandbox to play safely.) To implement sandboxing, Metabase runs a query that filters rows and/or selects a subset of columns from a table based on [the person's permissions][permissions]; the user's query then runs on the initial query's result.
Several databases did not support [common table expressions][cte] when sandboxing was added to Metabase, so we implemented it using subqueries. Suppose you use the Notebook Editor to create a query like:
```
SELECT *
FROM orders
WHERE price > 100.00
```
If the `orders` table is sandboxed by the user's ID, what we actually run is something like this:
```
SELECT
made_up_name_01.customer_id AS customer_id,
made_up_name_01.price AS price,
made_up_name_01.whatever AS whatever
FROM
(
SELECT
orders.customer_id AS customer_id,
orders.price AS price,
orders.whatever AS whatever
FROM
orders
WHERE
orders.customer_id = {% raw %} {{user_id}} {% endraw %}
)
made_up_name_01
WHERE
made_up_name_01.price > 100
```
Metabase creates a unique temporary name like `made_up_name_01` to make sure the query doesn't actually pull in data from an existing table. The curly braces `{% raw %}{{...}}{% endraw %}` around `user_id` show that it is bound to an attribute from the user properties.
Sandboxing isn't implemented for non-SQL databases like MongoDB, Druid, or Google Analytics. It also isn't implemented for native SQL questions: since we generate the SQL for questions written with the Notebook Editor, we can produce exactly what sandboxing needs, but parsing and modifying an arbitrary query written in SQL is a much (much) bigger challenge. As ar esult, any user with permissions to view the question can see all the results.
## Specific Problems
### People can see data they're not supposed to be able to see
**How to detect this:** People can view data that they shouldn't be able to.
**How to fix this:** The fix depends on the root cause.
1. Public questions can't be sandboxed: if someone doesn't have to log in to view the question, Metabase doesn't have user properties or group properties available for filtering the data, so all results will be shown. (We recommend that you *avoid* public sharing when you are sandboxing data.)
2. If the administrator didn't restrict access to the underlying table when setting up sandboxing, people will be able to see the original data. You can check this by going into the Admin Panel and viewing Permissions for the table in question.
3. [Signed embedding][signed-embedding] will show all results by default, though it's possible to control filtering with [locked parameters][locked-parameters]. Note that signed embedding depends only on the token generated by the including page, not whether someone is logged into Metabase or not.
4. If people are logging in with single sign-on, but the expected attributes aren't being saved and made available, sandboxing will deny access. Our article on [Authenticating with SAML][authenticating-with-saml] explains the required setup in detail.
### People can't see the data they're supposed to be able to see
**How to detect this:** Someone is supposed to be able to use some of the values in a table in their queries, but are denied access or get an empty set of results where there should be data.
**How to fix this:** Again, the fix depends on the root cause:
1. Administrators usually restrict access to tables as part of sandboxing. If the restrictions are too tight by mistake (e.g., "no access") then people might not be able to see any data at all. You can check this by going into the Admin Panel and viewing Permissions for the table in question.
2. Some fields in a table which the person *does* have sandbox access to are using remapping to display information from another table which the person does *not* have sandbox access to. You can check this by going into the Admin Panel and viewing the Data Model for the fields in question.
### Someone is in several groups but can't see the sandboxed data
We only allow [one sandbox per table][one-sandbox-per-table]: if someone is a member of two or more groups with different permissions, every rule for figuring out whether access should be allowed or not is confusing. We therefore only allow one rule.
**How to detect this:** The root cause of this problem is conceptual---administrators can't create several sandboxes for one table because we don't allow it.
**How to fix this:** The administrator can create a new group to capture precisely who's allowed access to what.
[authenticating-with-saml]: /docs/latest/enterprise-guide/authenticating-with-saml.html
[locked-parameters]: /learn/embedding/embedding-charts-and-dashboards.html#hide-or-lock-parameters-to-restrict-what-data-is-shown
[one-sandbox-per-table]: /docs/latest/enterprise-guide/data-sandboxes.html#a-user-can-only-have-one-sandbox-per-table
[permissions]: /learn/permissions/data-permissions.html
[prepared-statement]: /glossary.html#prepared-statement
[sandboxing-your-data]: /docs/latest/enterprise-guide/data-sandboxes.html
[signed-embedding]: /learn/embedding/embedding-charts-and-dashboards.html#enable-embedding-in-other-applications