A user or query/dashboard permission for external clients?


#1

Hi,
I’d love to see re:dash support a use case where we can provision a client to log in and only have view-only access to the Dashboards and Queries that we allow for them.

They would be able to:

  • View dashboards that they have access to
  • View queries that they have access to, in a read-only manner (this is optional)

They would NOT be able to:

  • View All Dashboards
  • View All Queries
  • View Recent Dashboards
  • View Recent Queries

With this feature, we can create a login for our clients, pre-configure a set of queries and dashboards for them that hit our common warehouse database, and let them experience the power of re:dash in a controlled, clean way.

Note that we can’t use the current approach of setting a group to have “View Only” rights to a database, because that user can access the list of “All Queries”, “Recent Queries”, and “Recent Dashboards”, which will leak information between clients.


Is there management dashboards function which according to user-specific permissions?
#2

+1

In my case I want to restrict access to management and non-technical users on my team instead of clients. The majority of our team is not tech savvy and would never collaborate with me in redash. Most of my users don’t need access to the majority of queries or dashboards for a given datasource. For example I’d like to have our accounting users only have access to queries and dashboards I explicitly share with them or their group, while preventing them from viewing other queries and dashboards (like customer service or shipping) even if they all use the same data source (our CMS).


#3

Note that we can’t use the current approach of setting a group to have “View Only” rights to a database, because that user can access the list of “All Queries”, “Recent Queries”, and “Recent Dashboards”, which will leak information between clients.

Eventually we will get full blown ACL and this pull request is a step in this direction. But until then what you can do is create a datasource per client (which is connected to the same database), and give them “View Only” access to this datasource only. This way each client will be able to see only the queries/dashboards you create with this datasource, and won’t see other queries/dashboards.

Few other notes:

  • Using the same Redash instance for all your clients, means they will see each other in the users list. You can disable this by removing their permission to list users (by editing the group they’re member of).
  • While we don’t list dashboards the user don’t have access to, they can still access them if they guess the URL. Even in this case they won’t see the data but only the text widgets and dashboard title. I don’t think it’s an issue, but it’s something to be aware of.

Permissions data
#4

In my case I want to restrict access to management and non-technical users on my team instead of clients. The majority of our team is not tech savvy and would never collaborate with me in redash. Most of my users don’t need access to the majority of queries or dashboards for a given datasource. For example I’d like to have our accounting users only have access to queries and dashboards I explicitly share with them or their group, while preventing them from viewing other queries and dashboards (like customer service or shipping) even if they all use the same data source (our CMS).

You can use the same approach I suggested @JasonShah, but it’s not something I recommend for “internal” usage. Unless you have a good reason to keep people from access to data, I suggest to give them access to the most data you can.

There are exceptions, sometimes it’s state regulations and sometimes it just the way your business operates. But if those don’t exist, just give everyone the same level of access. It will only benefit you and your organization, as you never know what people might find useful and relevant to their work.

80% of the people won’t look anyway beyond the dashboards you tell them to look at. But the magic happens with the other 20% of people.


#5

I tried this out today. I created a new datasource pointed to the shared database, new user, and new group with that new user and pointing to the new datasource. After I logged in as that user:

  • Permissions seem to fit well. I am locked out of queries that don’t map to the datasource.
  • However, when I go to a query the admin user explicitly created for this new user, I get a message that seems to indicate that I can’t access the content:
  • I cannot figure out how to change the group’s permission to prevent the user from listing users. All I seem to be able to change for the group is Members and Data Sources. Is there an undocumented UI somewhere to do this?

So, definitely closer than I originally thought.


#6

The message is a bug, that was fixed in v0.12. v0.12 is not released yet, but it’s stable enough if you want to upgrade to it.

I cannot figure out how to change the group’s permission to prevent the user from listing users. All I seem to be able to change for the group is Members and Data Sources. Is there an undocumented UI somewhere to do this?

It’s not possible to do from the UI. You need to edit the permissions column of the group row in the groups table. You will see an array of string there, each is self descriptive permission (the relevant one is list_users).


#7

Thanks @arikfr. I’ll upgrade after 0.12 hits release, test the flow again then, and post back to here afterwards.


#8

Version 0.12 fixed the permission issue screenshot I posted above, so that’s good.

However, changing the permissions array for the group in which the client user is, to "{create_dashboard,create_query,edit_dashboard,edit_query,view_query,view_source,execute_query,schedule_query,list_dashboards,list_alerts,list_data_sources}" (which is what it was before, minus list_users), didn’t actually remove the ability for the client user to be able to list all of the users. They couldn’t edit details about specific users, but they could still see all the users and their email addresses.


#9

It doesn’t seem right. When logged in with such user, if you open the browser console and type currentUser.permissions what do you get?