fix: datasource payload is incorrect #15184
Conversation
Codecov Report
@@ Coverage Diff @@
## master #15184 +/- ##
==========================================
+ Coverage 77.14% 77.23% +0.08%
==========================================
Files 973 973
Lines 50473 50496 +23
Branches 6183 6183
==========================================
+ Hits 38938 39000 +62
+ Misses 11329 11290 -39
Partials 206 206
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
| schema_perm | ||
| and security_manager.can_access("schema_access", schema_perm) | ||
| ): | ||
| user_datasources.extend(datasources) |
There was a problem hiding this comment.
oh! this makes me question the validity of the get methods on the MVC and API, they both depend on: https://github.com/apache/superset/blob/master/superset/views/base.py#L581
There was a problem hiding this comment.
Hmmm, do you think I also need to check for security_manager.can_access_all_datasources() here?
There was a problem hiding this comment.
can_access_database handles it
| user_datasources = set() | ||
| for datasource_class in ConnectorRegistry.sources.values(): | ||
| user_datasources.update( | ||
| session.query(datasource_class) |
There was a problem hiding this comment.
@betodealmeida @dpgaspar I believe this logic, i.e., relying on the fragile perm and schema_perm columns in the database, breaks if people are using a custom security manager. Should we be calling get_datasources_accessible_by_user instead?
Note I sense currently Superset doesn't do a great job of differentiating between metadata and data access. The get_datasources_accessible_by_user is somewhat of a misnomer as it is merely used for metadata access (for an awareness perspective).
There was a problem hiding this comment.
@john-bodley, get_datasources_accessible_by_user calls ConnectorRegistry.query_datasources_by_permissions, which uses the same logic I'm using here.
Since we're getting user_perms and schema_perms from the security manager (lines 108, 109) doesn't it means this works with custom security managers?
There was a problem hiding this comment.
@betodealmeida @john-bodley I think that the question here is that AirBnb totally overrides the DB permissions, they do that by overriding the security manager, their permission "backend" is something totally different. So that's possible if all permission checks are done on the security manager.
Makes me think how can that work on the REST API defined filters
There was a problem hiding this comment.
@dpgaspar that's correct. We actually don't use any of the FAB logic and thus we completely bypass the securiy_manager.user_view_menu_names and reliance of the datasource_class.perm and datasource_class.schema_perm database columns.
There was a problem hiding this comment.
@betodealmeida if the get_datasources_accessible_by_user method isn't ideal, then I think the alternatively would be to move the get_user_datasources method to the security manager so deployments can overwrite the logic if necessary.
This reverts commit 216e2b8.
This reverts commit 216e2b8.
This reverts commit f230b19.
This reverts commit f230b19.
* fix: datasource payload is incorrect * Add tests, clean code
* fix: datasource payload is incorrect * Add tests, clean code
* fix: datasource payload is incorrect * Add tests, clean code
mistercrunch
added
🏷️ bot
SUMMARY
We currently return all datasources in the
/datasources/and/chart/addendpoints. This PR changes the payload to have only user-accessible datasources.The PR adds a new method
get_user_datasources, which replacesget_all_datasourcesin the two views.BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N/A
TESTING INSTRUCTIONS
Will add unit tests, wanted to check the approach first.
ADDITIONAL INFORMATION