sadpandajoe commented on code in PR #43499:
URL: https://github.com/apache/superset/pull/43499#discussion_r4254294554
##########
superset/commands/chart/utils.py:
##########
@@ -33,15 +33,22 @@
def validate_chart_datasource_type(datasource_type: str) -> None:
"""Accept persistent chart sources with names and type-aware access
policies.
- SQL Lab queries are registered datasource types but are not persistent
- chart sources; accepting all DatasourceDAO registrations would include
them.
+ A raw SQL Lab ``query`` is a registered datasource type but not a
+ persistent chart source, so it's excluded here; accepting all
+ DatasourceDAO registrations would include it. A ``saved_query`` is
+ explicitly persisted and named by the user, so it's accepted alongside
+ ``table``/``semantic_view``.
"""
if (
datasource_type == DatasourceType.SEMANTIC_VIEW
and not is_semantic_layers_enabled()
):
raise ValidationError(SemanticLayersDisabledError.message)
- if datasource_type not in (DatasourceType.TABLE,
DatasourceType.SEMANTIC_VIEW):
+ if datasource_type not in (
+ DatasourceType.TABLE,
+ DatasourceType.SEMANTIC_VIEW,
+ DatasourceType.SAVEDQUERY,
Review Comment:
Accepting `saved_query` here still 500s on create/update, even for an Admin:
both commands call `raise_for_access(datasource=...)`, which reaches
`raise_for_unsupported_guest_rls()` and reads `datasource.type` before any role
check, and `SavedQuery` has no `type` attribute (the `"type"` key added to
`data` doesn't provide it). That would also explain the red unit and
integration jobs on the new 201 test. Could `SavedQuery` get a real `type` (and
whatever else `raise_for_access` reads) so the allow and deny paths are
exercised against the real model rather than a patched `raise_for_access`?
##########
superset/commands/chart/utils.py:
##########
@@ -33,15 +33,22 @@
def validate_chart_datasource_type(datasource_type: str) -> None:
"""Accept persistent chart sources with names and type-aware access
policies.
- SQL Lab queries are registered datasource types but are not persistent
- chart sources; accepting all DatasourceDAO registrations would include
them.
+ A raw SQL Lab ``query`` is a registered datasource type but not a
+ persistent chart source, so it's excluded here; accepting all
+ DatasourceDAO registrations would include it. A ``saved_query`` is
+ explicitly persisted and named by the user, so it's accepted alongside
+ ``table``/``semantic_view``.
"""
if (
datasource_type == DatasourceType.SEMANTIC_VIEW
and not is_semantic_layers_enabled()
):
raise ValidationError(SemanticLayersDisabledError.message)
- if datasource_type not in (DatasourceType.TABLE,
DatasourceType.SEMANTIC_VIEW):
+ if datasource_type not in (
+ DatasourceType.TABLE,
+ DatasourceType.SEMANTIC_VIEW,
+ DatasourceType.SAVEDQUERY,
Review Comment:
Once creation works, a non-editor whose only grant is `database_access` on
the saved query's database won't see these charts: `ChartFilter`
(`superset/charts/filters.py`) and `DashboardAccessFilter` join `Database` only
through `SqlaTable`, so the chart drops out of the list, GET returns 404, and a
published dashboard containing only that chart is filtered out too, even though
`raise_for_access` would allow the datasource. Should those filters also cover
saved-query-backed charts, or should the type stay rejected until they do?
##########
superset/models/sql_lab.py:
##########
@@ -602,6 +602,68 @@ def to_dict(self) -> dict[str, Any]:
"id": self.id,
}
+ @property
+ def name(self) -> str:
+ """
+ Expose ``label`` as ``name`` so callers that treat a ``SavedQuery`` as
+ a generic datasource (e.g. chart create/update commands) can rely on
+ a uniform ``name`` attribute across all datasource types.
+
+ ``label`` is a nullable column, so fall back to an id-based name
+ rather than returning ``None`` from a property typed as ``str``.
+ """
+ return self.label or f"Saved query {self.id}"
+
+ @property
+ def schema_perm(self) -> Optional[str]:
+ """
+ Schema-level permission string, mirroring ``Query.schema_perm``.
+
+ Required so that ``SecurityManager.raise_for_access(datasource=...)``
+ and the ``Slice`` ``before_insert``/``before_update`` listener (which
+ copies ``perm``/``catalog_perm``/``schema_perm`` onto the chart) can
+ treat a ``SavedQuery`` like any other datasource instead of raising
+ ``AttributeError``.
+ """
+ return security_manager.get_schema_perm(
+ self.database.database_name, self.catalog, self.schema
+ )
+
+ @property
+ def catalog_perm(self) -> Optional[str]:
+ """Catalog-level permission string; see ``schema_perm`` above."""
+ return security_manager.get_catalog_perm(
+ self.database.database_name, self.catalog
+ )
+
+ @property
+ def perm(self) -> str:
+ """Object-level permission string; see ``schema_perm`` above."""
+ return f"[{self.database.database_name}].[{self.name}](id:{self.id})"
+
+ @property
+ def data(self) -> ExplorableData:
+ """
+ Minimal explorable payload.
+
+ ``SecurityManager`` builds access-denied error messages (and a few
+ dashboard-RBAC lookups) off ``datasource.data["id"]``/``["name"]``
+ for *every* datasource type it can be asked to authorize, not just
+ ones that are actually explorable; without this a denied saved-query
+ chart request fails with ``AttributeError`` instead of the intended
+ 403.
+ """
+ result: ExplorableData = {
Review Comment:
With `name`/`data` now defined, can a Gamma user with Explore access read
another user's saved query metadata? `GetExploreCommand._authorize_datasource`
only authorizes the chart when `slice_id` is supplied, but form_data's
`datasource` overrides the chart's, so `GET
/api/v1/explore/?form_data={"slice_id":<own chart>,"datasource":"<other user's
id>__saved_query"}` would return that query's label, schema, catalog, database
id and backend without any saved-query ownership or database check. Is there a
check on the overridden datasource that I'm missing?
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
