[GitHub] [incubator-superset] axelet commented on issue #9532: Row Level Security filter wildcard for all tables and multiple table filters

[GitBox <gi...@apache.org>]

axelet commented on issue #9532:
URL: https://github.com/apache/incubator-superset/issues/9532#issuecomment-624671462


   @villebro 
   As for now I posted a version (https://github.com/apache/incubator-superset/pull/9751) where we have the same filters for different tables grouped together in one filter with multiple tables (Solution 2 described above, except that it doesn't support any wildcard logic). I also added a test to ensure that it works. The original behaviour is not changed for now. However, this doesn't cover the security case I described before. 
   
   As for your question about column not present in the table we can handle it by checking and filtering all clauses came from **_get_sqla_row_level_filters()** (if I got you correctly). We need them to have the filters specific columns, so we can check them in **SqlaTable.get_sqla_query()** and apply only appropriate ones. We have the **cols** dict with col_names, let's check the clauses to have the col_names. Or can we leave it as a user responsibility?
   
   For expr_qry and aliases I agree it can be circumvented as long as a potential admin grants the SQL Lab access to users. I'm not sure if it's possible without Sql Lab, could you provide any cases? So, I assume it could be done for users without SQL Lab rights (if only admins can create views). Please, correct me if I'm wrong. So, there is nothing we can do here if not introducing some wildcards for tables or schemas.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org