Short answer: No, TALISMAN_CONFIG and OAUTH_PROVIDERS are both static — they're set once at application startup and cannot be natively modified per-request or per-domain [1] [2].

That said, here are your options for a multi-domain, multi-tenant setup:

1. Talisman (CSP headers)

Since Talisman is initialized once via talisman.init_app() during app startup [1], the simplest approach is to list all 4 domains in your TALISMAN_CONFIG CSP directives (e.g., connect-src, frame-ancestors, etc.). This isn't "dynamic," but it covers all your domains in a single policy. If you truly need per-request CSP, you'd need to use ADDITIONAL_MIDDLEWARE [2] to inject custom WSGI middleware that inspects the Host or Origin header and overwrites the CSP response headers after Talisman sets them. This is not a supported pattern and requires careful implementation.

2. OAuth / Zitadel (dynamic provider selection by domain)

Superset's OAuth config (via Flask-AppBuilder) is static — there's no built-in mechanism to route to different Zitadel instances based on the request domain. Possible workarounds:

• Reverse proxy approach (recommended): Deploy a reverse proxy (Nginx, Traefik, etc.) in front of Superset that maps each of your 4 domains to different Superset instances (or to the same instance with different env-injected configs via SUPERSET_CONFIG environment variable). This is the cleanest separation.
• Custom Security Manager: Subclass SupersetSecurityManager and override the OAuth login flow to inspect request.host and dynamically set the authorization/token URLs for the correct Zitadel instance. This is non-trivial but technically feasible since Flask gives you access to the request context.
• FLASK_APP_MUTATOR: Use this hook [2] to register a before_request handler that inspects the domain and stores it in Flask's g object, which your custom security manager can then use.

3. Client-side API calls to domain-specific endpoints

For your custom forms that need to call APIs matching the user's domain, you can use JavaScript to read window.location.hostname and route API calls accordingly. This doesn't require any Superset backend changes.

Recommended architecture for your scenario:

The most robust approach for 4 domains with different network access and identity providers is to use a reverse proxy that routes each domain to either:

• Separate Superset instances (simplest, most isolated), or
• The same instance but with domain-aware middleware that sets the correct headers and OAuth redirect

A single Superset instance trying to dynamically serve 4 different security configurations is fighting against how Flask-Talisman and Flask-AppBuilder were designed. Infrastructure-level routing will give you the cleanest, most maintainable solution.

To reply, just mention @dosu.

Docs are dead. Just use Dosu.