Access control example?

[brylie]

We are looking to build a Django app that integrates multiple Dash apps. We would like to limit access to each of the dash apps based on Django auth. Is there an example of how we could use Django auth to provide group-based access control to Dash apps using this wrapper?

[delsim]

No explicit example yet, so we should add one.

Wrapping Django's login_required view helper around all of the views in django-plotly-dash/django_plotly_dash/urls.py is a quick way of enforcing a logged-in requirement on viewing any of the dash apps, and more fine-grained control is possible with a custom wrapper.

Is your goal to have an all-or-nothing control over access, or something more fine-grained that is perhaps on a per-dash-app-per-user basis?

[brylie]

Something more fine-grained would be desirable.

For example, our main goal would be to define groups of users, and grant a group access to one or more dashboards.

Perhaps even, different groups would see different charts when viewing the same 'dashboard page', if it would be possible to control include tags based on role.

[eddy-ojb]

Big topic..most of what you have described above is what i have created at work but there are so many variables and inplementation methods to think about that I'm not sure it's a good idea to include all that in a dpd demo.

For limiting access to different user, app and, in my case, client combinations, we made models to reflect these classes and an Authority table to drive permissions upon authentication, which involved standard django stuff.

What is unique is returning user dependent dashboards. I am wondering what the use case for this is? Is it realistic to just use callbacks to control this?

[brylie]

One use case would be to allow trusted users to manage permissions for a set of dashboards through the UI. E.g. a trusted user could view a dashboard and click 'add authorized user', selecting a user from a list who should have access to the dashboard. This would mean that each dashboard should be a first-class entity in the (database) system, so that an 'ACL' table or field could connect users to dashboards.

[delsim]

I've added functionality to wrap all views delegated to plotly dash through an arbitrary function specified in settings. The default is to do nothing; requiring a login is also trivial, and a user supplied function can be used for each view so we should be able to handle most (all?) requirements.

[GibbsConsulting]

The skeleton for access control has now been pushed as part of the 0.9.2 patch release

[Skitzi]

To expand on this idea, how could you leverage this to not only control access to a dash app but also apply data restrictions? SAy you have a single dash app with authenticated access, but then also want to limit data based on the user, or apply a user specific filter (show data only related to the individual as an example).

[brylie]

@Skitzi Are you using Django to model your database? At what level of access control do you want to restrict users (e.g. table, row, queryset, view)? There is, for example, a row-based access control plugin:

https://github.com/nnseva/django-access

[brylie]

Relatedly, Django can auto-generate models from an existing database, which might be useful to build an analytic application.

There is likely a measurable amount of overhead added by any authorization code, so it would be good to define at what level you want to authorize users. E.g. checking authorization for each database row might slow down analytic queries, whereas a view could be created that returns an authorized user with a queryset.

[Skitzi]

Thank you for the thoughts on this. I am using unmanged Django models to look at my existing data in a sql warehouse. I did use the auto-modeling which actually did a pretty good job, only a few small tweaks had to be made to get things working well for us. It would likely be row based, but my knowledge is a bit noobish here, well really with Python and Django as a whole. The thought is we will have a field on our user model to link it to a customer model we have. That customer model has an admin interface where we are thinking about exposing specific fields to be used as variables in our queries. We are using the Django ORM here but as an example we would have a single query with something like SELECT * FROM table WHERE orgID = . That would then be used in Dash to generate a number of different interactive charts. As far as load goes, I would assume 25-100 hits a day that would generate a DB query and dash display.

[brylie]

For this task, I recommend reading the django documentation on many-to-one and many-to-many relationships. You can use those relationships to build querysets that only return the desired rows.

Then, you can feed those querysets into the Dash app, but the main work here is done by django.

[brylie]

I've added functionality to wrap all views delegated to plotly dash through an arbitrary function specified in settings.

@delsim could you please add one or more code examples showcasing how to do this in the docs?