Hi Max,
thanks for the detailed response. We‘re already using RLS using RC3 (with the 
patch). In here the DB is currently used for making sure User rights are 
accounted for. Having said that we‘d prefer to use security filtering based on 
JWT parameter. So adding parameters on login to Jinja context would be 
favourable. Those could be used in RLS filtering going forward.
Please note this is also different to DB filtering as a SSO application can 
hand over a certain context (you named team). We have the use case that a 
single user might be assigned to multiple tenants and he can switch between 
them. So the JWT token will be set correspondingly and that info could be used 
to apply filtering more global than in a select. A select would not do it, as 
another SSO application is controlling the current context. So security 
definitely is a concern and we would not opt for a Jinja option if it‘s not 
bullet proof.

Thanks,
Dennis

> Am 11.04.2020 um 02:15 schrieb Maxime Beauchemin <maximebeauche...@gmail.com>:
> 
> Accessing `flask.g` in SQL Lab (in async mode) is tricky because the
> execution is run on a celery worker where there's no Flask context. I think
> we've done work before to make "current_username" available across the
> board (async/not async).
> http://superset.apache.org/sqllab.html#superset.jinja_context.current_username
> 
> We're also looking to move towards more of an async execution model across
> the board as detailed here:
> https://github.com/apache/incubator-superset/issues/9190. It'd be nice to
> have access to some current user-related object in Jinja templates in the
> async world too, and have some way to add user attributes (things like
> team, department, ...) to that user objects so that they can be referenced
> in that context. Clearly there are considerations around caching, security
> and privacy in that area.
> 
> I'm curious as to what you're trying to accomplish, is it some sort of
> row-level-security thing? We merge a RLS feature recently, wondering if
> that may work for you.
> https://github.com/apache/incubator-superset/pull/8699
> 
> Max
> 
>> On Tue, Apr 7, 2020 at 2:22 PM Dennis Meyer <den...@jdeluxe.org> wrote:
>> 
>> Hi,
>> 
>> We encountered an issue with RC3 on Table search boxes. I know there’s
>> been some bug reported on not emitting filters on selects, but now the
>> search doesn’t function any more at all. I will get some time tomorrow to
>> investigate further and track down a bug if I cannot overcome the issue.
>> But someone might want to cross check if search boxes (in Table Chart
>> advances settings) still works ok. Thanks!
>> 
>> As I’m already writing and StackOverflow is dead silent: I was wondering
>> how one could access the flask.g context using e.g. superset SQLLab. I'd
>> like to set a value on login and later use it in Jinja. Is this possible?
>> 
>> 
>> @expose('/login/', methods=['GET', 'POST'])
>>    def login(self):
>>            g.my_value = 'bar'
>>            …
>> In SQLLab:
>> {{flask.g.my_value}}
>> 
>> https://stackoverflow.com/questions/61088292/how-can-i-attach-a-value-at-login-time-for-jinja-and-reuse-it-later-on-in-apache
>> <
>> https://stackoverflow.com/questions/61088292/how-can-i-attach-a-value-at-login-time-for-jinja-and-reuse-it-later-on-in-apache
>>> 
>> 
>> Thanks,
>> Dennis

Reply via email to