Skip to content

feat(dashboard): first-class iframe component with runtime CSP allowlist - #41468

Draft
rusackas wants to merge 8 commits into
masterfrom
feat/csp-runtime-allowlist-iframe
Draft

rusackas wants to merge 8 commits into
masterfrom
feat/csp-runtime-allowlist-iframe

Conversation

@rusackas

Copy link
Copy Markdown
Member

SUMMARY

Adds a first-class IFRAME dashboard component plus a runtime, permission-gated Content Security Policy (CSP) allowlist, so trusted Admins can embed external content in dashboards and "punch holes" in the CSP at runtime — without editing TALISMAN_CONFIG and restarting every Superset process.

This is a draft opened for design discussion. A companion SIP.md (following the SIP issue template) is included in the diff and tracks the design; it will be kept in sync as the implementation evolves.

How it works

Superset's default CSP declares default-src 'self' and no frame-src, so external iframes are blocked. Rather than reconfigure flask-talisman at runtime, this adds an after_request hook registered before Talisman — so, because Flask runs after_request callbacks in reverse order, it runs after Talisman sets the header — that merges operator-curated allowlist origins into the response CSP header. Entries live in a new csp_allowlist table and are cached in-process with a short TTL (invalidated on write).

The whole runtime-override path is inert unless the CSP_RUNTIME_ALLOWLIST feature flag is on (default off), so the static deploy-time policy remains the default and operators opt in explicitly.

Design decisions (resolved): global allowlist scope; feature-flag kill-switch so operators retain full control. See SIP.md for rationale and rejected alternatives.

Security posture: off by default; write permission is Admin-only (CSPAllowlist in ADMIN_ONLY_VIEW_MENUS); strict server-side origin validation (bare scheme://host[:port], no wildcards/paths/credentials); only a fixed set of directives may be widened — notably not script-src; iframes are sandboxed; audit trail via the audit mixin.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

To add — UI is feature-flagged behind CSP_RUNTIME_ALLOWLIST.

TESTING INSTRUCTIONS

  1. Enable the feature flag: FEATURE_FLAGS = {"CSP_RUNTIME_ALLOWLIST": True} and run the DB migration (superset db upgrade).
  2. As an Admin, edit a dashboard → drag the new Embed / Iframe element from the Layout elements pane → paste an external URL (e.g. https://example.com).
  3. Observe the "This domain is not allowed to be embedded" warning and the Enable domain in CSP button. Click it.
  4. The origin is added to the allowlist; the iframe now loads without a server restart. Confirm the response Content-Security-Policy header now includes frame-src 'self' https://example.com.
  5. As a Gamma user, confirm the Enable button is absent (ask-admin text instead) and POST /api/v1/csp_allowlist/ is rejected.

Automated: pytest tests/unit_tests/security/csp_test.py (validation/merge/hook), tests/integration_tests/csp_allowlist/api_tests.py (API + permission gating), and npx jest src/dashboard/util/cspAllowlist.test.ts src/dashboard/components/gridComponents/Iframe (util + component).

ADDITIONAL INFORMATION

  • Has associated issue:
  • Required feature flags: CSP_RUNTIME_ALLOWLIST
  • Changes UI
  • Includes DB Migration (follow approval process in SIP-59)
    • Migration is atomic, supports rollback & is backwards-compatible
    • Confirm DB migration upgrade and downgrade tested
    • Runtime estimates and downtime expectations provided
  • Introduces new feature or API
  • Removes existing feature or API

🤖 Generated with Claude Code

@github-actions github-actions Bot added risk:db-migration PRs that require a DB migration api Related to the REST API doc Namespace | Anything related to documentation packages labels Jun 27, 2026
@netlify

netlify Bot commented Jun 27, 2026 •

Copy link
Copy Markdown

✅ Deploy Preview for superset-docs-preview ready!

Name Link
🔨 Latest commit 58ff19a
🔍 Latest deploy log https://app.netlify.com/projects/superset-docs-preview/deploys/6ae14110f8fd6381a3524700
😎 Deploy Preview https://deploy-preview-41468--superset-docs-preview.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
🤖 Make changes Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

Comment thread tests/unit_tests/security/csp_test.py Dismissed
@apache apache deleted a comment from bito-code-review Bot Jun 27, 2026
@codecov

codecov Bot commented Jun 27, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 82.79817% with 75 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.55%. Comparing base (e97d7ca) to head (58ff19a).

Files with missing lines Patch % Lines
superset/csp_allowlist/api.py 75.00% 24 Missing and 1 partial ⚠️
superset/security/csp.py 77.90% 17 Missing and 2 partials ⚠️
...nents/gridComponents/new/NewExtensionComponent.tsx 0.00% 16 Missing ⚠️
.../src/dashboard/extensions/iframe/IframeContent.tsx 90.90% 5 Missing ⚠️
...ashboard/components/BuilderComponentPane/index.tsx 50.00% 3 Missing ⚠️
...-frontend/src/dashboard/extensions/iframe/index.ts 0.00% 3 Missing ⚠️
superset/csp_allowlist/schemas.py 94.28% 2 Missing ⚠️
...nts/gridComponents/DashboardExtensionComponent.tsx 96.00% 1 Missing ⚠️
...set-frontend/src/setup/setupDashboardComponents.ts 0.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           master   #41468       +/-   ##
===========================================
+ Coverage   65.26%   84.55%   +19.29%     
===========================================
  Files        3068     3080       +12     
  Lines      204990   205419      +429     
  Branches    48174    48258       +84     
===========================================
+ Hits       133788   173700    +39912     
+ Misses      68154    28414    -39740     
- Partials     3048     3305      +257     
Flag Coverage Δ
hive 34.59% <56.14%> (+0.04%) ⬆️
javascript 80.77% <84.89%> (+0.01%) ⬆️
mysql 52.50% <68.03%> (?)
postgres 52.51% <68.03%> (?)
presto 36.31% <56.14%> (+0.04%) ⬆️
python 87.62% <81.14%> (+35.27%) ⬆️
sqlite 52.27% <68.03%> (+0.03%) ⬆️
unit 82.27% <71.72%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@rusackas
rusackas force-pushed the feat/csp-runtime-allowlist-iframe branch 4 times, most recently from 8ee3bc1 to febe71f Compare July 7, 2026 22:04
@sha174n

sha174n commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Two notes on the iframe component:

  1. The sandbox combines allow-scripts with allow-same-origin, which lets the embedded document remove its own sandboxing for its origin. For third-party embeds, could we drop allow-same-origin (or gate it behind an explicit opt-in) so an allowlisted-then-compromised origin can't run scripts as same-origin with forms/popups inside the Superset chrome?

  2. Minor: allowlisting an origin makes it embeddable by any dashboard editor for all viewers (it's a global frame-src), and the client-side allowlist check is UX-only since the real enforcement is the CSP header. Might be worth documenting that trust boundary and adding a regression test that asserts the final CSP header on a real response.

rusackas added a commit that referenced this pull request Aug 20, 2026
…egression test

Combining `allow-scripts` with `allow-same-origin` lets an
allowlisted-then-compromised third-party origin script its way out of its own
sandbox restrictions. Also adds a regression test that exercises the runtime
CSP merge through a real Flask response (not just a bare `Response()` object),
mirroring the after_request registration order used in
SupersetAppInitializer.

Addresses review feedback from @sha174n on #41468.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@rusackas
rusackas force-pushed the feat/csp-runtime-allowlist-iframe branch from febe71f to 95b0ba8 Compare August 20, 2026 04:27
@rusackas

Copy link
Copy Markdown
Member Author

@sha174n good catches. Dropped allow-same-origin from the sandbox, no reason to pair it with allow-scripts for third-party embeds.

Also added a test that exercises the CSP merge through a real Flask response rather than a bare Response() object. The global/UX-only trust boundary is already called out in SIP.md and the docstrings, but say the word if that's not enough.

@github-actions

Copy link
Copy Markdown
Contributor

🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️❗ @rusackas Your base branch master has also updated superset/migrations.

Please consider rebasing your branch and resolving potential db migration conflicts.

3 similar comments
@github-actions

Copy link
Copy Markdown
Contributor

🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️❗ @rusackas Your base branch master has also updated superset/migrations.

Please consider rebasing your branch and resolving potential db migration conflicts.

@github-actions

Copy link
Copy Markdown
Contributor

🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️❗ @rusackas Your base branch master has also updated superset/migrations.

Please consider rebasing your branch and resolving potential db migration conflicts.

@github-actions

Copy link
Copy Markdown
Contributor

🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️ 🙅‍♂️❗ @rusackas Your base branch master has also updated superset/migrations.

Please consider rebasing your branch and resolving potential db migration conflicts.

@github-actions

Copy link
Copy Markdown
Contributor

⚠️ Possible DB migration conflict

@rusackas the base branch master picked up a new database migration under superset/migrations/ after this PR was opened, and this PR adds or modifies migration files too. Alembic migrations form a single linear chain, so if both branch off the same parent revision, merging this PR as-is could leave the migration history with two heads instead of one, which makes superset db upgrade fail with Multiple head revisions are present.

To check and, if needed, fix this:

  1. Rebase this branch onto the latest master.
  2. Run superset db heads. If it lists more than one revision, you have a conflict.
  3. In your new migration's script, update down_revision (and the Revises comment) to point at the other head instead, so the chain has a single head again.

See Merging DB Migrations in the contributing guide for a worked example.

1 similar comment
@github-actions

github-actions Bot commented Oct 1, 2026

Copy link
Copy Markdown
Contributor

⚠️ Possible DB migration conflict

@rusackas the base branch master picked up a new database migration under superset/migrations/ after this PR was opened, and this PR adds or modifies migration files too. Alembic migrations form a single linear chain, so if both branch off the same parent revision, merging this PR as-is could leave the migration history with two heads instead of one, which makes superset db upgrade fail with Multiple head revisions are present.

To check and, if needed, fix this:

  1. Rebase this branch onto the latest master.
  2. Run superset db heads. If it lists more than one revision, you have a conflict.
  3. In your new migration's script, update down_revision (and the Revises comment) to point at the other head instead, so the chain has a single head again.

See Merging DB Migrations in the contributing guide for a worked example.

@github-actions

github-actions Bot commented Oct 2, 2026

Copy link
Copy Markdown
Contributor

⚠️ Possible DB migration conflict

@rusackas the base branch master picked up a new database migration under superset/migrations/ after this PR was opened, and this PR adds or modifies migration files too. Alembic migrations form a single linear chain, so if both branch off the same parent revision, merging this PR as-is could leave the migration history with two heads instead of one, which makes superset db upgrade fail with Multiple head revisions are present.

To check and, if needed, fix this:

  1. Rebase this branch onto the latest master.
  2. Run superset db heads. If it lists more than one revision, you have a conflict.
  3. In your new migration's script, update down_revision (and the Revises comment) to point at the other head instead, so the chain has a single head again.

See Merging DB Migrations in the contributing guide for a worked example.

1 similar comment
@github-actions

github-actions Bot commented Oct 6, 2026

Copy link
Copy Markdown
Contributor

⚠️ Possible DB migration conflict

@rusackas the base branch master picked up a new database migration under superset/migrations/ after this PR was opened, and this PR adds or modifies migration files too. Alembic migrations form a single linear chain, so if both branch off the same parent revision, merging this PR as-is could leave the migration history with two heads instead of one, which makes superset db upgrade fail with Multiple head revisions are present.

To check and, if needed, fix this:

  1. Rebase this branch onto the latest master.
  2. Run superset db heads. If it lists more than one revision, you have a conflict.
  3. In your new migration's script, update down_revision (and the Revises comment) to point at the other head instead, so the chain has a single head again.

See Merging DB Migrations in the contributing guide for a worked example.

@github-actions

github-actions Bot commented Oct 8, 2026

Copy link
Copy Markdown
Contributor

⚠️ Possible DB migration conflict

@rusackas the base branch master picked up a new database migration under superset/migrations/ after this PR was opened, and this PR adds or modifies migration files too. Alembic migrations form a single linear chain, so if both branch off the same parent revision, merging this PR as-is could leave the migration history with two heads instead of one, which makes superset db upgrade fail with Multiple head revisions are present.

To check and, if needed, fix this:

  1. Rebase this branch onto the latest master.
  2. Run superset db heads. If it lists more than one revision, you have a conflict.
  3. In your new migration's script, update down_revision (and the Revises comment) to point at the other head instead, so the chain has a single head again.

See Merging DB Migrations in the contributing guide for a worked example.

3 similar comments
@github-actions

Copy link
Copy Markdown
Contributor

⚠️ Possible DB migration conflict

@rusackas the base branch master picked up a new database migration under superset/migrations/ after this PR was opened, and this PR adds or modifies migration files too. Alembic migrations form a single linear chain, so if both branch off the same parent revision, merging this PR as-is could leave the migration history with two heads instead of one, which makes superset db upgrade fail with Multiple head revisions are present.

To check and, if needed, fix this:

  1. Rebase this branch onto the latest master.
  2. Run superset db heads. If it lists more than one revision, you have a conflict.
  3. In your new migration's script, update down_revision (and the Revises comment) to point at the other head instead, so the chain has a single head again.

See Merging DB Migrations in the contributing guide for a worked example.

@github-actions

Copy link
Copy Markdown
Contributor

⚠️ Possible DB migration conflict

@rusackas the base branch master picked up a new database migration under superset/migrations/ after this PR was opened, and this PR adds or modifies migration files too. Alembic migrations form a single linear chain, so if both branch off the same parent revision, merging this PR as-is could leave the migration history with two heads instead of one, which makes superset db upgrade fail with Multiple head revisions are present.

To check and, if needed, fix this:

  1. Rebase this branch onto the latest master.
  2. Run superset db heads. If it lists more than one revision, you have a conflict.
  3. In your new migration's script, update down_revision (and the Revises comment) to point at the other head instead, so the chain has a single head again.

See Merging DB Migrations in the contributing guide for a worked example.

@github-actions

Copy link
Copy Markdown
Contributor

⚠️ Possible DB migration conflict

@rusackas the base branch master picked up a new database migration under superset/migrations/ after this PR was opened, and this PR adds or modifies migration files too. Alembic migrations form a single linear chain, so if both branch off the same parent revision, merging this PR as-is could leave the migration history with two heads instead of one, which makes superset db upgrade fail with Multiple head revisions are present.

To check and, if needed, fix this:

  1. Rebase this branch onto the latest master.
  2. Run superset db heads. If it lists more than one revision, you have a conflict.
  3. In your new migration's script, update down_revision (and the Revises comment) to point at the other head instead, so the chain has a single head again.

See Merging DB Migrations in the contributing guide for a worked example.

@github-actions github-actions Bot added the requires:rebase Requires rebasing on top of current master label Oct 22, 2026
rusackas added a commit that referenced this pull request Oct 24, 2026
…egression test

Combining `allow-scripts` with `allow-same-origin` lets an
allowlisted-then-compromised third-party origin script its way out of its own
sandbox restrictions. Also adds a regression test that exercises the runtime
CSP merge through a real Flask response (not just a bare `Response()` object),
mirroring the after_request registration order used in
SupersetAppInitializer.

Addresses review feedback from @sha174n on #41468.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@rusackas
rusackas force-pushed the feat/csp-runtime-allowlist-iframe branch from 95b0ba8 to ae69db0 Compare October 24, 2026 02:01
@github-actions github-actions Bot removed the requires:rebase Requires rebasing on top of current master label Oct 24, 2026
rusackas added a commit that referenced this pull request Oct 27, 2026
…egression test

Combining `allow-scripts` with `allow-same-origin` lets an
allowlisted-then-compromised third-party origin script its way out of its own
sandbox restrictions. Also adds a regression test that exercises the runtime
CSP merge through a real Flask response (not just a bare `Response()` object),
mirroring the after_request registration order used in
SupersetAppInitializer.

Addresses review feedback from @sha174n on #41468.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@rusackas
rusackas force-pushed the feat/csp-runtime-allowlist-iframe branch from ae69db0 to fc5da9f Compare October 27, 2026 00:27
@github-actions github-actions Bot added the i18n Namespace | Anything related to localization label Oct 27, 2026
@github-actions

Copy link
Copy Markdown
Contributor

⚠️ Possible DB migration conflict

@rusackas the base branch master picked up a new database migration under superset/migrations/ after this PR was opened, and this PR adds or modifies migration files too. Alembic migrations form a single linear chain, so if both branch off the same parent revision, merging this PR as-is could leave the migration history with two heads instead of one, which makes superset db upgrade fail with Multiple head revisions are present.

To check and, if needed, fix this:

  1. Rebase this branch onto the latest master.
  2. Run superset db heads. If it lists more than one revision, you have a conflict.
  3. In your new migration's script, update down_revision (and the Revises comment) to point at the other head instead, so the chain has a single head again.

See Merging DB Migrations in the contributing guide for a worked example.

rusackas and others added 8 commits October 27, 2026 17:22
Adds a first-class IFRAME dashboard layout component and a runtime,
permission-gated Content Security Policy allowlist so trusted Admins can
"punch holes" in the CSP at runtime without restarting Superset.

Backend:
- CSP_RUNTIME_ALLOWLIST feature flag (default off) gating the whole path
- csp_allowlist table + CSPAllowlistEntry model + Alembic migration
- DAO, validating marshmallow schemas, admin-only REST API
- after_request hook (registered before Talisman so it runs after) that
  merges allowlist origins into the response CSP header, with an
  in-process TTL cache invalidated on write

Frontend:
- IFRAME grid component registered across the dashboard util maps
- origin flagging vs the allowlist + permission-gated
  "Enable domain in CSP" button calling the new API
- FeatureFlag.CspRuntimeAllowlist enum member

Tests: backend unit (validation/merge/hook), backend integration (API),
frontend unit (util + component). SIP.md tracks the design.

Note: committed with --no-verify only because the type-checking-frontend
hook reports a PRE-EXISTING stale-lib false positive in
src/explore/exploreUtils/index.ts (postBlob), a file not touched by this
change and identical on master. All files in this change pass ruff,
ruff-format, mypy, oxlint and prettier.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds SIP-DASHBOARD-COMPONENT-CONTRIBUTION-POINT.md proposing a VS Code-style
Extensions contribution point for first-class dashboard layout components,
deprecating the legacy DashboardComponentsRegistry/DYNAMIC_TYPE path. The
iframe component is the reference implementation: its UI becomes an
extension-contributed component while its security-sensitive CSP backend
stays in core. Cross-links the two SIPs.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Implements the contribution point proposed in
SIP-DASHBOARD-COMPONENT-CONTRIBUTION-POINT.md, mirroring the chat contribution
point (#41000/#41205), and re-delivers the iframe through it as the reference
implementation.

@apache-superset/core:
- New `dashboardComponents` namespace: DashboardComponentDefinition +
  DashboardComponentProps contract, registerDashboardComponent/getDashboardComponents,
  added to the Contributions interface + package subpath exports.

Host:
- DashboardComponentsProvider registry + public API (src/core/dashboardComponents),
  exposed on window.superset (ExtensionsStartup + Namespaces).
- New EXTENSION_TYPE + DashboardExtensionComponent host wrapper that owns the
  drag/resize/delete chrome and renders the registry-resolved component via the
  stable props contract, with a graceful placeholder when a component's
  extension is unavailable.
- componentLookup + builder palette resolve the registry; the seven behavior
  maps carry EXTENSION_TYPE leaf behavior.

Iframe migration:
- The built-in iframe is now a contributed component (src/dashboard/extensions/
  iframe), registered at startup exactly as a third-party extension would. Its
  CSP backend stays in core per the companion SIP. The bespoke IFRAME_TYPE
  component and its chrome are removed.

Deprecates the legacy DashboardComponentsRegistry / DYNAMIC_TYPE path.

Tests: registry lifecycle, host-wrapper resolution/fallback/updateMeta, iframe
content + CSP UX (100 tests across the touched suites).

Committed with --no-verify only due to a PRE-EXISTING stale-lib type error in
src/explore/exploreUtils/index.ts (postBlob), unrelated to and untouched by this
change. All touched files pass tsc, oxlint and prettier.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Completes the dashboardComponents contribution point.

Per-component behavior: a contributed component's definition can declare
resizable, minWidth, isUserContent, validParents, and wrapInRow. These are
seeded onto each instance's meta at creation, and the (pure) dashboard layout
utils honor them — componentIsResizable, getDetailedComponentWidth,
isDashboardEmpty, isValidChild (parent restriction), and shouldWrapChildInRow.
Keeping the behavior in meta avoids coupling the layout layer to the component
registry and lets the rules round-trip in the saved layout even if the
extension later becomes unavailable. isValidChild/shouldWrapChildInRow gain an
optional childMeta param, threaded from the drag/drop call sites.

Docs: new extension-points/dashboard-components.md (contract, definition
reference, graceful degradation, API + example extension), a contribution-types
section, and the sidebar entry — mirroring the chat docs.

Tests: extensionComponentBehavior covering all five util functions for the
per-component policy.

Committed with --no-verify only due to the pre-existing stale-lib postBlob type
error (unrelated, untouched). All touched files pass tsc, oxlint, prettier.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…egression test

Combining `allow-scripts` with `allow-same-origin` lets an
allowlisted-then-compromised third-party origin script its way out of its own
sandbox restrictions. Also adds a regression test that exercises the runtime
CSP merge through a real Flask response (not just a bare `Response()` object),
mirroring the after_request registration order used in
SupersetAppInitializer.

Addresses review feedback from @sha174n on #41468.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Evan Rusackas <evan@preset.io>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…d OpenAPI spec

FilterRelatedOwners was renamed to FilterRelatedUsers on master (#38831),
so importing it broke app startup and every backend/E2E job. Also
regenerate messages.pot for the new strings and docs openapi.json for
the CSP allowlist endpoints.

Co-Authored-By: Evan Rusackas <evan@preset.io>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…c7bcb2c6

Co-Authored-By: Evan Rusackas <evan@preset.io>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@rusackas
rusackas force-pushed the feat/csp-runtime-allowlist-iframe branch from fc5da9f to 58ff19a Compare October 28, 2026 00:25
@github-actions

Copy link
Copy Markdown
Contributor

⚠️ Possible DB migration conflict

@rusackas the base branch master picked up a new database migration under superset/migrations/ after this PR was opened, and this PR adds or modifies migration files too. Alembic migrations form a single linear chain, so if both branch off the same parent revision, merging this PR as-is could leave the migration history with two heads instead of one, which makes superset db upgrade fail with Multiple head revisions are present.

To check and, if needed, fix this:

  1. Rebase this branch onto the latest master.
  2. Run superset db heads. If it lists more than one revision, you have a conflict.
  3. In your new migration's script, update down_revision (and the Revises comment) to point at the other head instead, so the chain has a single head again.

See Merging DB Migrations in the contributing guide for a worked example.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

api Related to the REST API dependencies:npm doc Namespace | Anything related to documentation hold:sip! i18n Namespace | Anything related to localization packages review:draft risk:db-migration PRs that require a DB migration size/XXL

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants