You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@superset.apache.org by Dennis Meyer <de...@jdeluxe.org> on 2019/07/17 13:40:16 UTC
Tenant Filtering
Hi,
I’m, wondering which is the best approach to filter data per tenant. I saw there has been some PR, but it seems it’s dropped/never made it into the official release.
https://github.com/apache/incubator-superset/issues/5581 <https://github.com/apache/incubator-superset/issues/5581>
We have OAuth integration implemented but it’s pretty much useless if you cannot filter per client.
Can someone here elaborate the goto solution out of the box and the potential customizations? I’m thankful for any advise or hint.
Thanks in advance,
Dennis
Re: Tenant Filtering
Posted by Dennis Meyer <de...@jdeluxe.org>.
Created a GIT issue:
https://github.com/apache/incubator-superset/issues/7887 <https://github.com/apache/incubator-superset/issues/7887>
Happy to help out on the documentation of a sample implementation which uses the JINJA approach.
Dennis
> Am 17.07.2019 um 22:36 schrieb Ville Brofeldt <vi...@gmail.com>:
>
> Hi,
>
> the docs are confusing, I agree, and I was planning on working on said
> documentation in the near future. But the short answer: Jinja templating is
> not just limited to SQL Lab, but can be used much more universally.
>
> If you can open an issue on GitHub with as much info as you feel
> comfortable sharing with the community, it would be great to start working
> towards addressing your needs.
>
> Ville
>
> On Wed, Jul 17, 2019, 21:44 Dennis Meyer <de...@jdeluxe.org> wrote:
>
>> Hi Ville,
>>
>> Thanks for the resopnse. We have an account_id column in each table we
>> access with superset. Each user is allowed to see only rows of data for
>> matching account IDs (a user can be assigned to one or more account_ids).
>> No matter which datasource he’s using. Iin worst case it could be added to
>> all as it’s not that many, but security wise a one first all approach would
>> be favourable.
>>
>> Do I understand correctly the Ninja templates will also be applied to all
>> Dashboards & Slice queries (not only SqlLab)? The docs wasn’t that pecise
>> here and the infos I found sounded like it’s a SQLLab feature only.
>>
>> Thanks,
>> Dennis
>>
>>
>>
>>> On 17. Jul 2019, at 20:22, Ville Brofeldt <vi...@gmail.com>
>> wrote:
>>>
>>> Hi Dennis,
>>>
>>> depending on your data structure, you might be able to leverage the
>>> built-in support for Jinja templates, which can be embedded in SQL
>> queries,
>>> where or having clauses. So you could, for example, add a filter
>> "username
>>> = '{{ current_username() }}'" to filter only rows that apply to the
>> logged
>>> in user (btw, I also recently put through a PR #7816 to address problems
>>> arising from using Jinja templating with caching). If not, it would be
>>> interesting to hear more about your requirements to see if it can be
>> solved
>>> with existing functionality, or how much effort it would require to
>>> implement. I suggest opening an issue on GitHub so this can be explored
>> in
>>> more detail.
>>>
>>> Ville
>>>
>>> On Wed, Jul 17, 2019 at 4:40 PM Dennis Meyer <de...@jdeluxe.org> wrote:
>>>
>>>> Hi,
>>>> I’m, wondering which is the best approach to filter data per tenant. I
>> saw
>>>> there has been some PR, but it seems it’s dropped/never made it into the
>>>> official release.
>>>>
>>>> https://github.com/apache/incubator-superset/issues/5581 <
>>>> https://github.com/apache/incubator-superset/issues/5581>
>>>>
>>>> We have OAuth integration implemented but it’s pretty much useless if
>> you
>>>> cannot filter per client.
>>>> Can someone here elaborate the goto solution out of the box and the
>>>> potential customizations? I’m thankful for any advise or hint.
>>>>
>>>> Thanks in advance,
>>>> Dennis
>>>>
>>>>
>>
>>
Re: Tenant Filtering
Posted by Ville Brofeldt <vi...@gmail.com>.
Hi,
the docs are confusing, I agree, and I was planning on working on said
documentation in the near future. But the short answer: Jinja templating is
not just limited to SQL Lab, but can be used much more universally.
If you can open an issue on GitHub with as much info as you feel
comfortable sharing with the community, it would be great to start working
towards addressing your needs.
Ville
On Wed, Jul 17, 2019, 21:44 Dennis Meyer <de...@jdeluxe.org> wrote:
> Hi Ville,
>
> Thanks for the resopnse. We have an account_id column in each table we
> access with superset. Each user is allowed to see only rows of data for
> matching account IDs (a user can be assigned to one or more account_ids).
> No matter which datasource he’s using. Iin worst case it could be added to
> all as it’s not that many, but security wise a one first all approach would
> be favourable.
>
> Do I understand correctly the Ninja templates will also be applied to all
> Dashboards & Slice queries (not only SqlLab)? The docs wasn’t that pecise
> here and the infos I found sounded like it’s a SQLLab feature only.
>
> Thanks,
> Dennis
>
>
>
> > On 17. Jul 2019, at 20:22, Ville Brofeldt <vi...@gmail.com>
> wrote:
> >
> > Hi Dennis,
> >
> > depending on your data structure, you might be able to leverage the
> > built-in support for Jinja templates, which can be embedded in SQL
> queries,
> > where or having clauses. So you could, for example, add a filter
> "username
> > = '{{ current_username() }}'" to filter only rows that apply to the
> logged
> > in user (btw, I also recently put through a PR #7816 to address problems
> > arising from using Jinja templating with caching). If not, it would be
> > interesting to hear more about your requirements to see if it can be
> solved
> > with existing functionality, or how much effort it would require to
> > implement. I suggest opening an issue on GitHub so this can be explored
> in
> > more detail.
> >
> > Ville
> >
> > On Wed, Jul 17, 2019 at 4:40 PM Dennis Meyer <de...@jdeluxe.org> wrote:
> >
> >> Hi,
> >> I’m, wondering which is the best approach to filter data per tenant. I
> saw
> >> there has been some PR, but it seems it’s dropped/never made it into the
> >> official release.
> >>
> >> https://github.com/apache/incubator-superset/issues/5581 <
> >> https://github.com/apache/incubator-superset/issues/5581>
> >>
> >> We have OAuth integration implemented but it’s pretty much useless if
> you
> >> cannot filter per client.
> >> Can someone here elaborate the goto solution out of the box and the
> >> potential customizations? I’m thankful for any advise or hint.
> >>
> >> Thanks in advance,
> >> Dennis
> >>
> >>
>
>
Re: Tenant Filtering
Posted by Dennis Meyer <de...@jdeluxe.org>.
Hi Ville,
Thanks for the resopnse. We have an account_id column in each table we access with superset. Each user is allowed to see only rows of data for matching account IDs (a user can be assigned to one or more account_ids). No matter which datasource he’s using. Iin worst case it could be added to all as it’s not that many, but security wise a one first all approach would be favourable.
Do I understand correctly the Ninja templates will also be applied to all Dashboards & Slice queries (not only SqlLab)? The docs wasn’t that pecise here and the infos I found sounded like it’s a SQLLab feature only.
Thanks,
Dennis
> On 17. Jul 2019, at 20:22, Ville Brofeldt <vi...@gmail.com> wrote:
>
> Hi Dennis,
>
> depending on your data structure, you might be able to leverage the
> built-in support for Jinja templates, which can be embedded in SQL queries,
> where or having clauses. So you could, for example, add a filter "username
> = '{{ current_username() }}'" to filter only rows that apply to the logged
> in user (btw, I also recently put through a PR #7816 to address problems
> arising from using Jinja templating with caching). If not, it would be
> interesting to hear more about your requirements to see if it can be solved
> with existing functionality, or how much effort it would require to
> implement. I suggest opening an issue on GitHub so this can be explored in
> more detail.
>
> Ville
>
> On Wed, Jul 17, 2019 at 4:40 PM Dennis Meyer <de...@jdeluxe.org> wrote:
>
>> Hi,
>> I’m, wondering which is the best approach to filter data per tenant. I saw
>> there has been some PR, but it seems it’s dropped/never made it into the
>> official release.
>>
>> https://github.com/apache/incubator-superset/issues/5581 <
>> https://github.com/apache/incubator-superset/issues/5581>
>>
>> We have OAuth integration implemented but it’s pretty much useless if you
>> cannot filter per client.
>> Can someone here elaborate the goto solution out of the box and the
>> potential customizations? I’m thankful for any advise or hint.
>>
>> Thanks in advance,
>> Dennis
>>
>>
Re: Tenant Filtering
Posted by Ville Brofeldt <vi...@gmail.com>.
Hi Dennis,
depending on your data structure, you might be able to leverage the
built-in support for Jinja templates, which can be embedded in SQL queries,
where or having clauses. So you could, for example, add a filter "username
= '{{ current_username() }}'" to filter only rows that apply to the logged
in user (btw, I also recently put through a PR #7816 to address problems
arising from using Jinja templating with caching). If not, it would be
interesting to hear more about your requirements to see if it can be solved
with existing functionality, or how much effort it would require to
implement. I suggest opening an issue on GitHub so this can be explored in
more detail.
Ville
On Wed, Jul 17, 2019 at 4:40 PM Dennis Meyer <de...@jdeluxe.org> wrote:
> Hi,
> I’m, wondering which is the best approach to filter data per tenant. I saw
> there has been some PR, but it seems it’s dropped/never made it into the
> official release.
>
> https://github.com/apache/incubator-superset/issues/5581 <
> https://github.com/apache/incubator-superset/issues/5581>
>
> We have OAuth integration implemented but it’s pretty much useless if you
> cannot filter per client.
> Can someone here elaborate the goto solution out of the box and the
> potential customizations? I’m thankful for any advise or hint.
>
> Thanks in advance,
> Dennis
>
>