User based data filtering in Dash webapp

Filip_Pejsa

In a Dash webapp that requires Dataiku authentication we would like to filter displayed based on the webapp user. It is possible to retrieve the authenticated user in the webapp:

dataiku.api_client().get_auth_info_from_browser_headers(request_headers)

My question is how to best propagate the user ID to the backend so it can be used in filtering dataset that should be rendered to the user in the webapp.

Multiple users will use the webapp simultaneously, so concurrent calls have to be properly handled.

Thanks for ideas.

---

Operating system used: Windows 10

Sarina

Hi @Filip_Pejsa
,

One option is to trigger your filter recipe from a scenario, and make sure to poll to check if the scenario is already running, and wait to trigger the current scenario run once you know that the scenario is not currently running.

I am attaching an example project that includes a webapp that triggers a scenario, only once the scenario is not already running. You can import this project and try it out by going to +New Project > Import project. This approach should work well for you if the recipe runs fairly quickly and you simply want to ensure that concurrent runs never occur. For this approach, you could simply pass your filter_user variable to a project variable (since the scenario will never run concurrently),and you'll set the variable prior to triggering your scenario:

import dataiku 

client = dataiku.api_client()
project = client.get_default_project()
filter_user = dataiku.api_client().get_auth_info_from_browser_headers(request_headers)
['assocatedDSSUser']

project.update_variables({'user': filter_user})

You can then use the variable in your filter recipe. My example is of a Flask webapp, and I know you are using a Dash webapp, but you can likely implement similar logic in the Dash webapp.

One other option would be to generate a copy of the filter recipe through the Python API each time that the user triggers the webapp, setting the user as a recipe variable in the "newly created recipe". Your webapp can then run the "duplicated" recipe and destroy the duplicated recipe each time the webapp is used. This would allow you to always generate separate recipe runs from the webapp each time it's called, and you would never have to worry about concurrency. I am also happy to provide a code sample of this approach if you are interested in this approach instead.

Let me know what you think about these approaches and if you have any questions.

Thanks,
Sarina

Yesasvini Sai Meghana

https://community.dataiku.com/discussion/comment/30732#Comment_30732

Hey Sarina,
I'm also working on a project which has similar requirements. And the second approach mentioned by you sounds interesting. Would you be able to provide a sample code for iit please?

Thanks,

Meghana