sadpandajoe commented on code in PR #44406:
URL: https://github.com/apache/superset/pull/44406#discussion_r4320138868
##########
superset/charts/data/api.py:
##########
@@ -448,6 +448,15 @@ def _run_async(
return self._send_chart_response(result)
except ChartDataCacheLoadError:
pass
+ except (
Review Comment:
This new 400 branch for a failed cached read-back has no test. A warm
dataframe whose annotation layer references a chart the viewer cannot access
reaches it, but the existing `_run_async` tests only cover a cache hit and a
cache miss, so deleting this handler would leave them green and the request
would return a 500. Could a test make `command.execute(force_cached=True)`
raise `ChartDataQueryFailedError` and assert a 400 with no task submitted?
##########
superset/common/query_context_processor.py:
##########
@@ -331,6 +342,26 @@ def get_df_payload_result(
# nonce reads the freshly-cached result instead of recomputing
it.
self._mark_force_executed(query_obj, cache_key,
cache.result_persisted)
+ # Annotation data is fetched per requesting user (and, for chart-backed
+ # layers, scoped by the referenced chart datasource's RLS), so it is
+ # resolved and cached under its own entry — independent of whether the
+ # (shareable) dataframe above was a hit or a miss — rather than forcing
+ # every viewer of the same chart onto their own full dataframe copy.
+ annotation_data: dict[str, Any] = {}
+ if query_obj and annotation_key and cache.status != QueryStatus.FAILED:
+ try:
+ annotation_data = self._get_annotation_data_cached(
Review Comment:
The read-back after a joined task succeeds does not go through the
`force_cached` probe: `requestChartDataResolved` reissues it with
`enableAsyncMode: false`, so `_run_async` is never entered and viewer B's
missing annotation entry is computed inline with `force_cached=False`. A slow
annotation query can therefore still exceed the request timeout after the task
reported success. Should the annotation scope be part of the task identity, or
be warmed by the task, so each viewer's entry exists before completion?
##########
superset/common/query_context_processor.py:
##########
@@ -449,34 +481,189 @@ def query_cache_key(self, query_obj: QueryObject,
**kwargs: Any) -> str | None:
)
return cache_key
- def _annotation_cache_context(self, query_obj: QueryObject) -> dict[str,
Any]:
+ def annotation_cache_key(self, query_obj: QueryObject) -> str | None:
+ """
+ Cache key for this query's annotation-layer payload, or ``None`` when
+ the query has no annotation layers.
+
+ Annotation payloads are fetched under the requesting user's access
+ scope, which is a stricter security requirement than the dataframe
+ itself has. Keying them separately from :meth:`query_cache_key` keeps
+ that scoping from forcing every distinct viewer of an annotated chart
+ onto their own full copy of the (potentially much larger) shared
+ dataframe: users with the same access scope share this key too.
"""
- Cache-key material binding cached annotation data to its security
- context.
+ if not query_obj or not query_obj.annotation_layers:
+ return None
+ return self.query_cache_key(
+ query_obj,
annotation_context=self._annotation_cache_context(query_obj)
+ )
- Annotation payloads are fetched per requesting user and stored on the
- same cache entry as the dataframe, so the key also binds the requesting
- user and, for chart-backed layers, the RLS clauses of the referenced
- chart's datasource.
+ def _annotation_cache_context(self, query_obj: QueryObject) -> dict[str,
Any]:
+ """
+ Cache-key material binding annotation data to its security *scope* so
+ users with the same access share a cache entry and users with a
+ different scope — or no access — never read each other's data.
+
+ * NATIVE layers: the ``can_read`` permission on ``Annotation``, the
+ only user-dependent dimension of these global records.
+ * Chart-backed (``line``/``table``) layers: see
+ :meth:`_annotation_source_scope`.
"""
- source_rls: dict[str, list[str] | None] = {}
+ context: dict[str, Any] = {}
+
+ if any(
+ layer.get("sourceType") == "NATIVE" for layer in
query_obj.annotation_layers
+ ):
+ context["annotation_read"] = security_manager.can_access(
+ "can_read", "Annotation"
+ )
+
+ source_scope: dict[str, Any] = {}
for layer in query_obj.annotation_layers:
if (
layer.get("sourceType")
not in ANNOTATION_SOURCE_TYPES_WITH_CHART_REFERENCE
):
continue
layer_value = layer.get("value")
+ source_scope[str(layer_value)] =
self._annotation_source_scope(layer)
+ if source_scope:
+ context["source_scope"] = source_scope
+
+ return context
+
+ def _annotation_source_scope(self, layer: dict[str, Any]) -> dict[str,
Any]:
+ """
+ Access and data-identity cache-key material for one chart-backed
+ annotation layer.
+
+ ``access`` keeps a user denied the referenced chart's datasource from
+ reading an authorized user's cached payload. When the chart has a
+ saved query context, this runs the *same* authorization path
+ :meth:`get_viz_annotation_data` executes
+ (``QueryContext.raise_for_access``) rather than the coarser
+ :meth:`SecurityManager.can_access_datasource` — a requester whose
+ access comes from a dashboard/viewer-promiscuous-mode bypass (which
+ depends on the chart's own saved ``form_data``, e.g. its
+ ``slice_id``/``dashboardId``) would otherwise still fail that coarser,
+ context-free check and collapse onto the same denied scope as a
+ genuinely unauthorized requester, letting the latter read the
+ former's cached payload. ``data_key`` is the annotation chart's own
+ query cache key(s) — derived from the same, override-applied query
+ objects actually executed (see :meth:`_apply_annotation_overrides`),
+ so it captures the datasource version, RLS clauses, and any per-user
+ Jinja/virtual-dataset RLS material exactly as the live fetch would,
+ including material an override only introduces at a finer grain.
+ Reusing this logic avoids re-deriving it and automatically inherits
+ any future correctness fixes made there.
+ """
+ layer_value = layer.get("value")
+ datasource = None
+ try:
chart = (
ChartDAO.find_by_id(layer_value) if layer_value is not None
else None
)
- annotation_datasource = chart.datasource if chart else None
- source_rls[str(layer.get("value"))] = (
- security_manager.get_rls_cache_key(annotation_datasource)
- if annotation_datasource
- else None
+ # resolved_datasource, not datasource: the latter is pinned to
+ # table-backed datasources and resolves to None for a
+ # semantic-view-backed chart, which would otherwise collapse
+ # every requester onto the same {access: None, data_key: None}
+ # scope below regardless of their actual access.
+ datasource = chart.resolved_datasource if chart else None
+ if chart is None or datasource is None:
+ return {"access": None, "data_key": None}
+
+ annotation_query_context = chart.get_query_context()
+ if annotation_query_context is not None:
+ self._apply_annotation_overrides(annotation_query_context,
layer)
+ try:
+ annotation_query_context.raise_for_access()
+ access: Any = True
+ except SupersetSecurityException:
+ access = False
+ data_key: Any = [
+ annotation_query_context.query_cache_key(query_object)
Review Comment:
The concern is the referenced chart, not the host. When the source chart's
saved query context has `result_type="samples"` and metrics, `data_key` is
derived from the unprepared query, but the live fetch runs it through
`_prepare_samples_query`, which clears the metrics. An RLS clause that calls
`current_user_id()` only when metrics are absent gives both viewers the same
key but user-specific rows, so the second viewer is served the first viewer's
rows. Should the key be derived from the query after result-type preparation?
##########
superset/common/query_context_processor.py:
##########
@@ -474,73 +503,226 @@ def query_cache_key(self, query_obj: QueryObject,
**kwargs: Any) -> str | None:
)
return cache_key
- def _annotation_cache_context(self, query_obj: QueryObject) -> dict[str,
Any]:
+ def annotation_cache_key(self, query_obj: QueryObject) -> str | None:
"""
- Cache-key material binding cached annotation data to its security
- context.
-
- Annotation payloads are fetched per requesting user and stored on the
- same cache entry as the dataframe, so the key also binds the requesting
- user and, for chart-backed layers, the RLS clauses of the referenced
- chart's datasource.
+ Cache key for this query's annotation-layer payload, or ``None`` when
+ the query has no annotation layers or when some layer's access scope
+ could not be resolved (the payload is then never cached, see
+ :meth:`_annotation_source_scope`).
+
+ Annotation payloads are fetched under the requesting user's access
+ scope, which is a stricter security requirement than the dataframe
+ itself has. Keying them separately from :meth:`query_cache_key` keeps
+ that scoping from forcing every distinct viewer of an annotated chart
+ onto their own full copy of the (potentially much larger) shared
+ dataframe: users with the same access scope share this key too.
"""
- source_rls: dict[str, list[str] | None] = {}
- source_versions: dict[str, tuple[str, str]] = {}
- metadata_versions: dict[str, str] = {}
+ if not query_obj or not query_obj.annotation_layers:
+ return None
+ if (annotation_context := self._annotation_cache_context(query_obj))
is None:
+ return None
+ return self.query_cache_key(query_obj,
annotation_context=annotation_context)
+
+ def _annotation_cache_context(
+ self, query_obj: QueryObject
+ ) -> dict[str, Any] | None:
+ """
+ Cache-key material binding annotation data to its security *scope* so
+ users with the same access share a cache entry and users with a
+ different scope — or no access — never read each other's data.
+
+ * NATIVE layers: the ``can_read`` permission on ``Annotation``, the
+ only user-dependent dimension of these global records.
+ * Chart-backed (``line``/``table``) layers: see
+ :meth:`_annotation_source_scope`, recorded per *layer* (not per
+ referenced chart) since two layers can reference the same chart
+ with different overrides, and so different scopes.
+
+ Returns ``None`` when any layer's scope cannot be resolved, meaning
+ the payload must not be cached at all.
+ """
+ context: dict[str, Any] = {}
+
+ if any(
+ layer.get("sourceType") == "NATIVE" for layer in
query_obj.annotation_layers
+ ):
+ context["annotation_read"] = security_manager.can_access(
+ "can_read", "Annotation"
+ )
+
+ source_scope: list[dict[str, Any]] = []
for layer in query_obj.annotation_layers:
if (
layer.get("sourceType")
not in ANNOTATION_SOURCE_TYPES_WITH_CHART_REFERENCE
):
continue
- layer_value = layer.get("value")
+ if (scope := self._annotation_source_scope(layer)) is None:
+ return None
+ source_scope.append({"value": str(layer.get("value")), **scope})
+ if source_scope:
+ context["source_scope"] = source_scope
+
+ return context
+
+ def _annotation_source_scope(self, layer: dict[str, Any]) -> dict[str,
Any] | None:
+ """
+ Access and data-identity cache-key material for one chart-backed
+ annotation layer, or ``None`` when it cannot be resolved.
+
+ ``None`` means "do not cache": a missing chart, a chart with neither
+ a saved query context nor a resolvable datasource, or any error while
+ deriving the scope would otherwise collapse an authorized and a
+ denied requester onto one shared identity, letting the latter read
+ the former's warmed payload. The caller fetches live instead.
+
+ ``access`` keeps a user denied the referenced chart's datasource from
+ reading an authorized user's cached payload. When the chart has a
+ saved query context, this runs the *same* authorization path
+ :meth:`get_viz_annotation_data` executes
+ (``QueryContext.raise_for_access``) rather than the coarser
+ :meth:`SecurityManager.can_access_datasource` — a requester whose
+ access comes from a dashboard/viewer-promiscuous-mode bypass (which
+ depends on the chart's own saved ``form_data``, e.g. its
+ ``slice_id``/``dashboardId``) would otherwise still fail that coarser,
+ context-free check and collapse onto the same denied scope as a
+ genuinely unauthorized requester, letting the latter read the
+ former's cached payload. ``data_key`` is the annotation chart's own
+ query cache key(s) — derived from the same, override-applied query
+ objects actually executed (see :meth:`_apply_annotation_overrides`),
+ so it captures the datasource version, RLS clauses, and any per-user
+ Jinja/virtual-dataset RLS material exactly as the live fetch would,
+ including material an override only introduces at a finer grain.
+ Reusing this logic avoids re-deriving it and automatically inherits
+ any future correctness fixes made there.
+ """
+ layer_value = layer.get("value")
+ try:
chart = (
ChartDAO.find_by_id(layer_value) if layer_value is not None
else None
)
- annotation_datasource: Datasource | None = (
- chart.resolved_datasource if chart else None
- )
- if chart and isinstance(chart.query_context, str):
+ if chart is None:
+ return None
+
+ # The saved query context is what the live fetch executes and
+ # authorizes against, so it is consulted first, independent of
+ # the chart's own datasource pointer: a chart can have its
+ # ``datasource_id`` cleared while its saved query context still
+ # targets a valid dataset, and the live fetch would still work.
+ annotation_query_context = chart.get_query_context()
+ if annotation_query_context is not None:
+ self._apply_annotation_overrides(annotation_query_context,
layer)
try:
- source: dict[str, Any] = json.loads(chart.query_context)[
- "datasource"
- ]
- annotation_datasource = DatasourceDAO.get_datasource(
- source["type"], source["id"]
- )
- except (
- ValueError,
- TypeError,
- KeyError,
- DatasourceNotFound,
- DatasourceTypeNotSupportedError,
- DatasourceValueIsIncorrect,
- ):
- annotation_datasource = None
+ annotation_query_context.raise_for_access()
+ access: Any = True
+ except SupersetSecurityException:
+ access = False
+ data_key: Any = [
+ annotation_query_context.query_cache_key(query_object)
Review Comment:
The comparison to the source chart's own cache doesn't hold when that chart
sets `cache_timeout=-1`: it never caches, so nothing is shared there, but the
annotation entry is still written under the host chart's TTL with the same key
for both viewers. That serves the first viewer's total to the second even
though the source opted out of caching. Should annotation caching be skipped
when the referenced chart's cache is disabled?
--
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]
