henry3260 opened a new pull request, #72924:
URL: https://github.com/apache/airflow/pull/72924
## Why
`GET /dags/{dag_id}/dagRuns/{dag_run_id}/upstreamAssetEvents` only checked
that the caller may read the consuming Dag run and that they hold a coarse,
class-level asset read permission. It then returned every asset event the run
consumed, straight from the `DagRun.consumed_asset_events` relationship,
without scoping the events themselves.
For auth managers that authorize assets and Dags individually, this exposed
events of assets the caller may not read, and events produced by source Dags
the caller may not read. Each event carries the asset's `name`, `uri`, `group`
and `extra`, plus `source_dag_id`, `source_task_id` and `source_run_id`. The
same events are already hidden from `GET /assets/events` by
`ReadableAssetEventsFilterDep` and `ReadableAssetEventsByAssetFilterDep`, so
reading the consuming run was a way around that filtering.
## What
- `airflow-core/src/airflow/api_fastapi/core_api/routes/public/dag_run.py`:
`get_upstream_asset_events` now looks up the run's primary key (still 404 when
missing), then selects the consumed events through the `dagrun_asset_event`
association table and applies the same per-source-Dag and per-asset readability
filters as `GET /assets/events`. `total_entries` is the filtered count, so
hidden events do not leak through the total either.
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (Claude Fable 5.1)
--
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]
