You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by "worker123-tech (via GitHub)" <gi...@apache.org> on 2026/03/26 04:00:20 UTC
[D] Superset API: 404 Not Found when updating dashboard using access_token + csrf_token (but works with browser session) [superset]
GitHub user worker123-tech created a discussion: Superset API: 404 Not Found when updating dashboard using access_token + csrf_token (but works with browser session)
### Environment
* Superset version: 6.1.0rc1
* Deployment: Docker
* Authentication: REST API (`/api/v1/security/login`) + CSRF
---
### Problem Description
I am trying to update a dashboard via the API:
```http
PUT /api/v1/dashboard/{pk}
```
---
### ✅ Working Case (Browser / curl copied from DevTools)
When I copy the `curl` request directly from the browser DevTools and execute it, the update succeeds.
This request includes:
* session cookie
* csrf token
* proper headers
---
### ❌ Failing Case (Programmatic API flow)
I tried to reproduce the same behavior using API calls:
1. Login to get `access_token`:
```http
POST /api/v1/security/login
```
2. Get CSRF token:
```http
GET /api/v1/security/csrf_token/
```
3. Send request:
```http
PUT /api/v1/dashboard/{pk}
```
with headers:
```http
Authorization: Bearer <access_token>
X-CSRFToken: <csrf_token>
Cookie: <session cookie>
Content-Type: application/json
```
---
### ❗ Actual Result
```text
404 Not Found
```
---
### Expected Result
Dashboard should be updated successfully (same as browser behavior).
---
### Key Observation
* The same endpoint works when using browser session (copied curl)
* Fails when using access_token + csrf_token
* All requests are executed in the same session context (cookie preserved)
---
### Additional Notes
* If Authorization header is removed and only cookie is used → works
* If using Bearer token → returns 404 instead of 401/403
---
### Question
Is there a mismatch between:
* session-based authentication
* token-based authentication
* CSRF validation
in Superset 6.1.0rc1?
Or is mixing `access_token` and session cookie unsupported for write APIs?
---
### Request
Clarification on the correct way to:
* Authenticate API requests
* Use CSRF with Bearer token
* Update dashboard programmatically
---
Thanks!
GitHub link: https://github.com/apache/superset/discussions/38869
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Superset API: 404 Not Found when updating dashboard using access_token + csrf_token (but works with browser session) [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
GitHub user dosubot[bot] added a comment to the discussion: Superset API: 404 Not Found when updating dashboard using access_token + csrf_token (but works with browser session)
<!-- Answer -->
This is a known behavior pattern in Superset. The **404 error doesn't mean the dashboard doesn't exist** — it means the authentication context is causing the dashboard to be filtered out by the [`DashboardAccessFilter`](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/dashboards/filters.py#L104-L193) before the request is processed.
**Root Cause**: When you call `/api/v1/security/csrf_token/` without the `Authorization` header, the session cookie isn't associated with the authenticated user. This causes subsequent requests to have mismatched authentication contexts.
**Correct Flow**:
```python
import requests
# 1. Login
login_resp = requests.post(
"https://superset.example.com/api/v1/security/login",
json={"username": "admin", "password": "password", "provider": "db"}
)
access_token = login_resp.json()["access_token"]
# 2. Get CSRF token WITH Authorization header (critical!)
session = requests.Session()
session.headers.update({"Authorization": f"Bearer {access_token}"})
csrf_resp = session.get("https://superset.example.com/api/v1/security/csrf_token/")
csrf_token = csrf_resp.json()["result"]
# 3. Extract session cookie value
session_cookie = session.cookies.get("session")
# 4. Set all headers explicitly
session.headers.update({
"Authorization": f"Bearer {access_token}",
"X-CSRFToken": csrf_token,
"Cookie": f"session={session_cookie}" # Just the value, not full Set-Cookie
})
# 5. Update dashboard
resp = session.put(f"https://superset.example.com/api/v1/dashboard/{pk}", json={...})
```
**Key Points**:
- The `/api/v1/security/csrf_token/` endpoint [must be called with the Authorization header](https://github.com/apache/superset/discussions/35997) to properly associate the session with your authenticated user
- Session cookies are [only set via the CSRF endpoint or web login](https://github.com/apache/superset/discussions/33585#discussioncomment-13278652), not from `/api/v1/security/login`
- You may need to [explicitly set the Cookie header](https://github.com/apache/superset/issues/37930) even when using `requests.Session()`
**Additional Check**: If the **Public role** has `can read on Dashboard` permissions, [it can interfere with Bearer token authentication](https://github.com/apache/superset/discussions/38814#discussioncomment-16286730). Remove those permissions from the Public role if present.
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=brand-link).*
---
<sup>How did I do? [Good](https://app.dosu.dev/response-feedback/515ab20d-1391-49a3-bafa-dca6e642ba82?feedback_type=great_response&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/515ab20d-1391-49a3-bafa-dca6e642ba82?feedback_type=irrelevant_answer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/515ab20d-1391-49a3-bafa-dca6e642ba82?feedback_type=incorrect_sources&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/515ab20d-1391-49a3-bafa-dca6e642ba82?feedback_type=too_verbose&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/515ab20d-1391-49
a3-bafa-dca6e642ba82?feedback_type=hallucination&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/515ab20d-1391-49a3-bafa-dca6e642ba82?feedback_type=bug_report&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-bug_report) | [Other](https://app.dosu.dev/response-feedback/515ab20d-1391-49a3-bafa-dca6e642ba82?feedback_type=other&utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-other)</sup>
[](https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=chat-badge) [](https://cursor.com/link/prompt?text=This%20is%20a%20known%20behavior%20pattern%20in%20Superset.%20The%20%2A%2A404%20error%20doesn%27t%20mean%20the%20dashboard%20doesn%27t%20exist%2A%2A%20%E2%80%94%20it%20means%20the%20authentication%20context%20is%20causing%20the%20dashboard%20to%20be%20filtered%20out%20by%20the%20%5B%60DashboardAccessFilter%60%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/dashboards/filters.py%23L104-L193%29%20before%20the%20request%20is%20processed.%0A%0A%2A%2ARoot%20Cause%2A%2A%3A%20When%20you%20call%20%60/api/v1/security/csrf_token/%60%20without%20the%20%60Authorization%60%20header%2C%20the%20session%20cookie%20isn%27t%20associated%20with%20
the%20authenticated%20user.%20This%20causes%20subsequent%20requests%20to%20have%20mismatched%20authentication%20contexts.%0A%0A%2A%2ACorrect%20Flow%2A%2A%3A%0A%60%60%60python%0Aimport%20requests%0A%0A%23%201.%20Login%0Alogin_resp%20%3D%20requests.post%28%0A%20%20%20%20%22https%3A//superset.example.com/api/v1/security/login%22%2C%0A%20%20%20%20json%3D%7B%22username%22%3A%20%22admin%22%2C%20%22password%22%3A%20%22password%22%2C%20%22provider%22%3A%20%22db%22%7D%0A%29%0Aaccess_token%20%3D%20login_resp.json%28%29%5B%22access_token%22%5D%0A%0A%23%202.%20Get%20CSRF%20token%20WITH%20Authorization%20header%20%28critical%21%29%0Asession%20%3D%20requests.Session%28%29%0Asession.headers.update%28%7B%22Authorization%22%3A%20f%22Bearer%20%7Baccess_token%7D%22%7D%29%0Acsrf_resp%20%3D%20session.get%28%22https%3A//superset.example.com/api/v1/security/csrf_token/%22%29%0Acsrf_token%20%3D%20csrf_resp.json%28%29%5B%22result%22%5D%0A%0A%23%203.%20Extract%20session%20cookie%20value%0Asession_cookie%20%3
D%20session.cookies.get%28%22session%22%29%0A%0A%23%204.%20Set%20all%20headers%20explicitly%0Asession.headers.update%28%7B%0A%20%20%20%20%22Authorization%22%3A%20f%22Bearer%20%7Baccess_token%7D%22%2C%0A%20%20%20%20%22X-CSRFToken%22%3A%20csrf_token%2C%0A%20%20%20%20%22Cookie%22%3A%20f%22session%3D%7Bsession_cookie%7D%22%20%20%23%20Just%20the%20value%2C%20not%20full%20Set-Cookie%0A%7D%29%0A%0A%23%205.%20Update%20dashboard%0Aresp%20%3D%20session.put%28f%22https%3A//superset.example.com/api/v1/dashboard/%7Bpk%7D%22%2C%20json%3D%7B...%7D%29%0A%60%60%60%0A%0A%2A%2AKey%20Points%2A%2A%3A%0A-%20The%20%60/api/v1/security/csrf_token/%60%20endpoint%20%5Bmust%20be%20called%20with%20the%20Authorization%20header%5D%28https%3A//github.com/apache/superset/discussions/35997%29%20to%20properly%20associate%20the%20session%20with%20your%20authenticated%20user%0A-%20Session%20cookies%20are%20%5Bonly%20set%20via%20the%20CSRF%20endpoint%20or%20web%20login%5D%28https%3A//github.com/apache/superset/discussio
ns/33585%23discussioncomment-13278652%29%2C%20not%20from%20%60/api/v1/security/login%60%0A-%20You%20may%20need%20to%20%5Bexplicitly%20set%20the%20Cookie%20header%5D%28https%3A//github.com/apache/superset/issues/37930%29%20even%20when%20using%20%60requests.Session%28%29%60%0A%0A%2A%2AAdditional%20Check%2A%2A%3A%20If%20the%20%2A%2APublic%20role%2A%2A%20has%20%60can%20read%20on%20Dashboard%60%20permissions%2C%20%5Bit%20can%20interfere%20with%20Bearer%20token%20authentication%5D%28https%3A//github.com/apache/superset/discussions/38814%23discussioncomment-16286730%29.%20Remove%20those%20permissions%20from%20the%20Public%20role%20if%20present.) [](https://go.dosu.dev/discord-bot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=join-discord) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20help
ed%20me%20solve%20this%20issue!&url=https%3A//github.com/apache/superset/discussions/38869)
GitHub link: https://github.com/apache/superset/discussions/38869#discussioncomment-16320771
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Superset API: 404 Not Found when updating dashboard using access_token + csrf_token (but works with browser session) [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
GitHub user dosubot[bot] edited a comment on the discussion: Superset API: 404 Not Found when updating dashboard using access_token + csrf_token (but works with browser session)
<!-- Answer -->
This is a known behavior pattern in Superset. The **404 error doesn't mean the dashboard doesn't exist** — it means the authentication context is causing the dashboard to be filtered out by the [`DashboardAccessFilter`](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/dashboards/filters.py#L104-L193) before the request is processed.
**Root Cause**: When you call `/api/v1/security/csrf_token/` without the `Authorization` header, the session cookie isn't associated with the authenticated user. This causes subsequent requests to have mismatched authentication contexts.
**Correct Flow**:
```python
import requests
# 1. Login
login_resp = requests.post(
"https://superset.example.com/api/v1/security/login",
json={"username": "admin", "password": "password", "provider": "db"}
)
access_token = login_resp.json()["access_token"]
# 2. Get CSRF token WITH Authorization header (critical!)
session = requests.Session()
session.headers.update({"Authorization": f"Bearer {access_token}"})
csrf_resp = session.get("https://superset.example.com/api/v1/security/csrf_token/")
csrf_token = csrf_resp.json()["result"]
# 3. Extract session cookie value
session_cookie = session.cookies.get("session")
# 4. Set all headers explicitly
session.headers.update({
"Authorization": f"Bearer {access_token}",
"X-CSRFToken": csrf_token,
"Cookie": f"session={session_cookie}" # Just the value, not full Set-Cookie
})
# 5. Update dashboard
resp = session.put(f"https://superset.example.com/api/v1/dashboard/{pk}", json={...})
```
**Key Points**:
- The `/api/v1/security/csrf_token/` endpoint [must be called with the Authorization header](https://github.com/apache/superset/discussions/35997) to properly associate the session with your authenticated user
- Session cookies are [only set via the CSRF endpoint or web login](https://github.com/apache/superset/discussions/33585#discussioncomment-13278652), not from `/api/v1/security/login`
- You may need to [explicitly set the Cookie header](https://github.com/apache/superset/issues/37930) even when using `requests.Session()`
**Additional Check**: If the **Public role** has `can read on Dashboard` permissions, [it can interfere with Bearer token authentication](https://github.com/apache/superset/discussions/38814#discussioncomment-16286730). Remove those permissions from the Public role if present.
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=reply-with-mention&utm_term=apache%2Fsuperset).*
---
Share context across your team and agents. Try [Dosu](https://dosu.dev?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-tagline&utm_term=apache%2Fsuperset).
[](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-feedback&utm_term=apache%2Fsuperset&message_id=515ab20d-1391-49a3-bafa-dca6e642ba82) [](https://github.dosu.com/apache/superset?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-learn-repo&utm_term=apache%2Fsuperset) [](https://app.dosu.dev/signup?referrer=openSource&source=github-footer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-add-team&utm_term=apache%2Fsuperset)
GitHub link: https://github.com/apache/superset/discussions/38869#discussioncomment-16320771
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Superset API: 404 Not Found when updating dashboard using access_token + csrf_token (but works with browser session) [superset]
Posted by "worker123-tech (via GitHub)" <gi...@apache.org>.
GitHub user worker123-tech added a comment to the discussion: Superset API: 404 Not Found when updating dashboard using access_token + csrf_token (but works with browser session)
The problem is that using the exact same request flow, calls to /api/v1/theme are authenticated as the admin user, while calls to /api/v1/dashboard/{pk} are instead treated as coming from an anonymous user. Is there any additional header required when calling /api/v1/dashboard/{pk} compared to other endpoints?
GitHub link: https://github.com/apache/superset/discussions/38869#discussioncomment-16322047
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Superset API: 404 Not Found when updating dashboard using access_token + csrf_token (but works with browser session) [superset]
Posted by "worker123-tech (via GitHub)" <gi...@apache.org>.
GitHub user worker123-tech added a comment to the discussion: Superset API: 404 Not Found when updating dashboard using access_token + csrf_token (but works with browser session)
@dosubot[bot]
GitHub link: https://github.com/apache/superset/discussions/38869#discussioncomment-16322527
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org