Login redirection does not use subpath prefix

[thiagogquinto]

I am using Traefik as a proxy for Superset, and I want to access the Superset app through the /analytics subpath.

I set the following environment variable:

SUPERSET_APP_ROOT="/analytics"

I can access Superset using the /analytics subpath, but after logging in, I am redirected to:

https://localhost/superset/welcome/

However, the correct URL should be:

https://localhost/analytics/superset/welcome/

What configurations should I add or change?

Below are the labels I am using for Superset:

- "traefik.enable=true"
- "traefik.http.routers.superset.rule=Host(`localhost`) && PathPrefix(`/analytics`)"
- "traefik.http.routers.superset.entrypoints=websecure"
- "traefik.http.routers.superset.tls=true"
- "traefik.http.services.superset.loadbalancer.server.port=8088"

[dosubot[bot]]

Hi @thiagogquinto! I'm Dosu and I’m helping the superset team.

This is a known bug in Superset where post-login redirects don't respect SUPERSET_APP_ROOT. The fix was merged in PR #37942 and is available in Superset 6.1+. If you're on 6.0.0, you'll need to upgrade to get the fix.

In addition to setting SUPERSET_APP_ROOT, you should also configure your Traefik proxy to pass the X-Forwarded-Prefix header and enable the proxy fix in Superset. Here's what to add:

In your superset_config.py:

ENABLE_PROXY_FIX = True
PROXY_FIX_CONFIG = {"x_for": 1, "x_proto": 1, "x_host": 1, "x_port": 1, "x_prefix": 1}

In your Traefik labels, add a middleware to set the forwarded prefix header:

- "traefik.http.middlewares.superset-prefix.headers.customrequestheaders.X-Forwarded-Prefix=/analytics"
- "traefik.http.routers.superset.middlewares=superset-prefix"

Also make sure your Traefik configuration strips the /analytics prefix before forwarding to Superset (so that Superset receives /superset/welcome/ rather than /analytics/superset/welcome/), since SUPERSET_APP_ROOT handles prepending the prefix on the response side. You can use Traefik's StripPrefix middleware for this:

- "traefik.http.middlewares.superset-strip.stripprefix.prefixes=/analytics"
- "traefik.http.routers.superset.middlewares=superset-strip,superset-prefix"

Key points:

• This login redirect bug was fixed after Superset 6.0.0 [1] [2]
• The X-Forwarded-Prefix header is critical for proper URL generation behind a reverse proxy [3]
• Be careful about double-prefixing — ensure your proxy strips the prefix before forwarding, and let Superset's SUPERSET_APP_ROOT handle adding it back [4]

What version of Superset are you running? If you're on 6.1+ and still seeing this issue, there may be additional configuration needed.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[dosubot[bot]]

There's no specific documentation in the Superset repo about integrating Open WebUI with Superset's MCP server, so I can only speak to the Superset side of the equation.

Superset MCP auth today:

• On 6.1.0, the only supported authentication method is MCP_DEV_USERNAME — you set a single Superset username in superset_config.py, and all MCP tool calls execute as that delegated account. No JWT or Bearer token auth is supported yet in this release [1].

• On master, JWT-based user resolution has been reworked. The MCP server now resolves users via FastMCP's per-request JWT context (instead of relying on Flask's g.user), and MCP_USER_RESOLVER is wired up and functional [2]. Multi-issuer JWT setups require a custom issuer-aware resolver [3].

The key question for Open WebUI is whether it forwards a per-user Bearer token with each MCP request or uses a single shared token configured by an admin. If Open WebUI sends a single shared token, all users would share one Superset identity regardless of the auth method — collapsing row-level security, dataset permissions, and audit trails to one principal [1]. I wasn't able to verify Open WebUI's specific MCP token-forwarding behavior from the sources available, so you'd want to check Open WebUI's documentation on that point.

If per-user isolation matters (different Superset roles/RLS per user), you'd need the MCP client to pass a distinct JWT per user, and you'd need to be running on master (or a future release) where JWT auth is supported. On 6.1.0, there's no way around the single-identity limitation of MCP_DEV_USERNAME.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[thiagogquinto]

How to create a role with permission on Superset inicialization?
@dosu

[dosubot[bot]]

There are two main approaches to create roles with permissions automatically at Superset initialization:

Option 1: FLASK_APP_MUTATOR in superset_config.py

This hook runs after the app initializes, giving you access to the security manager to create roles and assign permissions programmatically:

def FLASK_APP_MUTATOR(app):
    from superset import security_manager as sm

    with app.app_context():
        # Create the role if it doesn't already exist
        role = sm.find_role("MyCustomRole")
        if not role:
            role = sm.add_role("MyCustomRole")

        # Find an existing permission and assign it to the role
        pvm = sm.find_permission_view_menu("can_read", "Dashboard")
        if pvm and pvm not in role.permissions:
            sm.add_permission_role(role, pvm)

        # Optionally copy all permissions from a built-in role
        gamma_role = sm.find_role("Gamma")
        if gamma_role:
            for pvm in gamma_role.permissions:
                sm.add_permission_role(role, pvm)

This approach is idempotent if you check find_role before creating, so it's safe to run on every container restart.

Option 2: PUBLIC_ROLE_LIKE for the Public/anonymous role

If you specifically need to configure the Public role for anonymous access, use this config shortcut:

PUBLIC_ROLE_LIKE = "Gamma"  # copies all Gamma permissions to the Public role

This is applied automatically every time superset init runs via sync_role_definitions() [1].

Key security manager methods you can use:

• sm.add_role("RoleName") — creates a role [2]
• sm.find_role("RoleName") — looks up an existing role
• sm.find_permission_view_menu("permission", "view") — finds a specific permission/view pair [3]
• sm.add_permission_role(role, pvm) — assigns a permission to a role (inherited from Flask-AppBuilder's SecurityManager)
• sm.sync_role_definitions() — syncs all built-in role definitions, equivalent to running superset init [1]

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[thiagogquinto]

how to know which permission/view pair to use?
@dosu

[dosubot[bot]]

There are a few practical ways to discover which permission/view pairs exist and which ones to use:

1. Query the database directly

After running superset init (which calls sync_role_definitions to create and sync all permissions), all available permission/view pairs live in the metadata DB:

SELECT p.name AS permission, v.name AS view_menu
FROM ab_permission_view pv
JOIN ab_permission p ON pv.permission_id = p.id
JOIN ab_view_menu v ON pv.view_menu_id = v.id
ORDER BY v.name, p.name;

You can filter with WHERE v.name LIKE '%Dashboard%' to narrow results.

2. Use the security manager in a Python shell

superset shell

from superset import security_manager as sm

# Dump all permissions for a specific role (great starting point)
gamma = sm.find_role("Gamma")
for pvm in gamma.permissions:
    print(f"{pvm.permission.name} | {pvm.view_menu.name}")

The Gamma role is computed by _is_gamma_pvm which excludes admin-only, alpha-only, SQL Lab-only, and object-specific permissions — making it a good baseline for custom roles [1].

3. Check via the Superset UI

Go to Security → List Roles, click Edit on any role (e.g. Gamma or Alpha), and the Permissions field shows all assigned permission/view pairs. You can search interactively to discover what's available [2].

Common permission/view pairs for reference:

What you want	Permission	View
View dashboards	can_read	Dashboard
View charts	can_read	Chart
Explore/run queries on charts	can_explore_json	Superset
SQL Lab access	can_sqllab	Superset
Bootstrap/current user info	can_read	CurrentUserRestApi
Log activity	can_log	Superset

[3]

There are also hardcoded sets in the SupersetSecurityManager class that define how permissions map to built-in roles — for example, SQLLAB_ONLY_PERMISSIONS lists all SQL Lab-specific pairs like (can_sqllab, Superset) and (can_execute_sql_query, SQLLab) [4], and create_custom_permissions registers pairs like can_share_dashboard/Superset, can_view_query/Dashboard, and can_drill/Dashboard [5].

The safest approach for building a custom role is to dump the Gamma role's permissions as a baseline, then add or remove specific entries for your needs.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.