DatabaseRestApi.get_list and DatasetRestApi.get_list return count:0 for JWT-authenticated Admin users in 6.0.1

[gkhnelbstn]

Bug description

DatabaseRestApi.get_list and DatasetRestApi.get_list return count:0 for JWT-authenticated Admin users in 6.0.1

Labels: bug, needs-triage

---

Bug description

When authenticating via the REST API using a JWT Bearer token (POST /api/v1/security/login), the /api/v1/database/ and /api/v1/dataset/ list endpoints always return count: 0 and an empty result array — even for users with the Admin role who have all_database_access and all_datasource_access permissions, and even when the objects exist in the metadata database.

The same user can see all objects correctly in the Superset UI (browser session). The issue is specific to JWT Bearer token authentication used by programmatic clients (MCP servers, provisioning scripts, FastAPI backends, etc.).

Steps to reproduce

1. Start Superset 6.0.1 with default config (WTF_CSRF_ENABLED = True)
2. Create at least one database connection and one dataset via the UI
3. Authenticate via the REST API:

import requests

resp = requests.post(
    "http://localhost:8088/api/v1/security/login",
    json={"username": "admin", "password": "admin", "provider": "db", "refresh": True}
)
token = resp.json()["access_token"]
headers = {"Authorization": f"Bearer {token}"}

4. Call the database list endpoint:

r = requests.get("http://localhost:8088/api/v1/database/", headers=headers)
print(r.status_code, r.json()["count"])
# Output: 200  0

5. Call the dataset list endpoint:

r = requests.get("http://localhost:8088/api/v1/dataset/", headers=headers)
print(r.status_code, r.json()["count"])
# Output: 200  0

Both return 200 OK with count: 0 and result: [], despite objects existing in the DB.

Root cause (identified)

DatabaseFilter.apply() in superset/databases/filters.py calls security_manager.can_access_all_databases(), which internally calls self.can_access("all_database_access", "all_database_access"), which reads g.user.

In Superset 6.0.1, when a request is authenticated via JWT Bearer token, flask-jwt-extended's user_lookup_loader sets g.user correctly — but only after the FAB before_request hook runs, which resets g.user to current_user (the Flask-Login anonymous proxy). As a result, g.user.is_anonymous returns True inside DatabaseFilter.apply(), causing can_access_all_databases() to return False.

When can_access_all_databases() returns False, the filter falls through to:

return query.filter(
    or_(
        self.model.perm.in_(database_perms),
        self.model.database_name.in_(database_names),
    )
)

However, the perm column was removed from the dbs table in Superset 6.x. This causes a silent failure that results in an empty result set rather than raising an exception.

Superset logs showing the silent failure:

ERROR:superset.views.error_handling:'encrypted_extra'
KeyError: 'encrypted_extra'

This secondary error occurs on GET /api/v1/database/_info because the extra JSON field in older dbs rows is missing the encrypted_extra key expected by 6.0.1.

Workaround

Add a before_request hook in superset_config.py that explicitly sets g.user from the JWT token before FAB's hook can reset it:

def FLASK_APP_MUTATOR(app):
    from flask import g, request

    @app.before_request
    def _set_user_from_jwt():
        auth_header = request.headers.get("Authorization", "")
        if auth_header.startswith("Bearer "):
            token = auth_header.split(" ", 1)[1]
            try:
                from flask_jwt_extended import decode_token
                decoded = decode_token(token)
                identity = decoded.get("sub")
                if identity:
                    from superset import security_manager
                    user = security_manager.load_user(identity)
                    if user and user.is_active:
                        g.user = user
            except Exception:
                pass

After applying this workaround, both endpoints return the correct count and result.

Expected behavior

GET /api/v1/database/ and GET /api/v1/dataset/ should return all objects visible to the authenticated user when using JWT Bearer token authentication, consistent with browser session behavior.

Actual behavior

Both endpoints return count: 0 and result: [] for JWT-authenticated requests, regardless of the user's role or permissions.

Superset version

6.0.1

Python version

3.10

Browser

N/A (API client)

Additional context

• The dbs table perm column referenced in DatabaseFilter was removed in 6.x. The filter's fallback branch silently fails when this column is missing.
• A secondary issue: dbs rows created before 6.0.1 may be missing the encrypted_extra key in the extra JSON field, causing KeyError: 'encrypted_extra' on GET /api/v1/database/_info. Fix:

  UPDATE dbs
  SET extra = (extra::jsonb || '{"encrypted_extra": ""}')::text
  WHERE extra NOT LIKE '%encrypted_extra%';

• Both issues compound to make the REST API completely non-functional for programmatic clients (MCP servers, provisioning scripts, FastAPI backends) that use JWT auth.

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

3.10

Node version

I don't know

Browser

Not applicable

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

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

This is a frequently reported issue across Superset 4.1.x through 6.x. The core problem is that JWT Bearer tokens alone don't establish the session cookies that Superset's authorization filters depend on. Your token authenticates the request (hence 200 OK), but g.user isn't fully resolved when the filters run, so can_access_all_databases() falls through to anonymous/empty permissions and silently returns zero results [1] [2].

A similar discussion was recently resolved with the same diagnosis [3].

Recommended workaround — use a requests.Session() and hit the CSRF endpoint with the Authorization header before making list calls. This establishes the session cookie that the filters need:

import requests

session = requests.Session()

# 1. Login
login_resp = session.post(
    "http://localhost:8088/api/v1/security/login",
    json={"username": "admin", "password": "admin", "provider": "db", "refresh": True}
)
access_token = login_resp.json()["access_token"]

# 2. Fetch CSRF token WITH the Bearer header — this establishes the session cookie
session.headers.update({"Authorization": f"Bearer {access_token}"})
csrf_resp = session.get("http://localhost:8088/api/v1/security/csrf_token/")
csrf_token = csrf_resp.json()["result"]
session.headers.update({"X-CSRFToken": csrf_token})

# 3. List endpoints now return results
r = session.get("http://localhost:8088/api/v1/database/")
print(r.json()["count"])  # should be > 0

One small correction to the root cause analysis: the perm column on dbs was removed back in Superset 1.0.0, not 6.x — it's now a hybrid_property that dynamically generates the permission string. So the fallback filter branch (self.model.perm.in_(database_perms)) does still execute, but it returns nothing because database_perms is empty when g.user isn't properly resolved.

Your before_request hook workaround is also valid and arguably cleaner for headless/programmatic clients (MCP servers, etc.) that can't easily manage session cookies. Both approaches solve the same underlying issue of g.user not being populated when the authorization filters run.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Dipanshusinghh]

@gkhnelbstn Thanks for the detailed report. I was able to reproduce the issue in Superset 6.0.1.

It looks like JWT-authenticated requests are not correctly populating g.user before the authorization filters execute, causing can_access_all_databases() to treat the request as anonymous.

I’ll try to investigate the request lifecycle between flask-jwt-extended and FAB’s before_request hooks and see if I can propose a fix or cleaner integration for JWT auth.

[hjadm]

Confirming this bug on Superset 6.0.0 using the Docker image apache/superset:6.0.0.

I was able to confirm that the issue affects the following REST API endpoints when using JWT Bearer authentication:

GET /api/v1/database/ → count: 0 ❌
GET /api/v1/dataset/ → count: 0 ❌
GET /api/v1/dashboard/ → count: 0 ❌
GET /api/v1/chart/ → count: 0 ❌

After applying the workaround, all four endpoints started returning the correct counts, for example:

database: 2
dataset: 55
dashboard: 26
chart: 508

The workaround was applied successfully using FLASK_APP_MUTATOR:

def FLASK_APP_MUTATOR(app):
from flask import g, request
from flask_jwt_extended import decode_token
from superset import security_manager

@app.before_request
def _set_user_from_jwt():
    auth_header = request.headers.get("Authorization", "")
    if auth_header.startswith("Bearer "):
        token = auth_header.split(" ", 1)[1]
        try:
            decoded = decode_token(token)
            identity = decoded.get("sub")
            if identity:
                user = security_manager.load_user(identity)
                if user and user.is_active:
                    g.user = user
        except Exception:
            pass

Important note: adding @app.before_request directly inside superset_config.py without using FLASK_APP_MUTATOR does not work. It fails with:

ImportError: cannot import name 'app' from 'superset.app'

So FLASK_APP_MUTATOR appears to be the correct mechanism here, because it receives the fully initialized Flask app instance.

A secondary fix was also necessary. The encrypted_extra KeyError on:

GET /api/v1/database/_info

required the following SQL fix:

UPDATE dbs
SET extra = (extra::jsonb || '{"encrypted_extra": ""}')::text
WHERE extra NOT LIKE '%encrypted_extra%';

After applying both fixes and restarting the container, all tested REST API endpoints worked correctly with JWT Bearer authentication.

I also confirmed that guest token generation works correctly after the fix:

POST /api/v1/security/guest_token/ → 200

This endpoint was also affected, since it depends on g.user.

Verified in production on a multi-tenant Superset deployment serving embedded dashboards.

[AndrewMatveev]

Add a before_request hook in superset_config.py that explicitly sets g.user from the JWT token before FAB's hook can reset it:

OMG it work on Superset 4.1.2. I search solution 2 weeks)

[sadpandajoe]

@dosubot has this been fixed as part of 6.1.0? If so which PR fixed it?

[dosubot]

This has not been fixed yet. PR #39946 was opened specifically to fix this issue (#39834), but it is currently open and unmerged [1].

That PR resolves the JWT user before permission filters run, so list results match the authenticated user instead of falling back to public/anonymous access. It also includes regression tests for JWT database and dataset list requests and invalid Bearer token handling.

No other merged PR fully addresses this specific problem for the core REST API list endpoints. Several related PRs have improved JWT handling in adjacent areas (MCP auth hooks, /api/v1/me, API key auth), but none fix the g.user population timing issue that causes the list filters to return empty results.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[venkatamandavilli-code]

Thanks for the detailed report. This looks like a regression introduced by stricter validation or behavioral changes in newer Superset versions.

Since the issue appears during embedded dashboard usage, it may help to verify whether:

• guest token permissions changed between versions
• RLS filters are being applied differently
• chart/dataset metadata assumptions became stricter in v6

There are already a few embedded-dashboard related regressions reported after upgrading to 6.x, especially around query generation and access handling. It would probably help to compare the generated SQL/query payload between the working version and the failing version to isolate what changed internally.

Also, if this only happens in embedded mode and not in the normal dashboard view, that would strongly point toward guest user context or embedded security handling.