GitHub user dosubot[bot] added a comment to the discussion: Superset API Auth Issue (Expecting cookies instead of access_token)
<!-- Answer --> You cannot obtain a session cookie directly via the /v1/security/login API endpoint. This endpoint is designed to return JWT access and refresh tokens, not browser session cookies, which is why you do not see a Set-Cookie header in the response when calling it programmatically. This is a known limitation and has been discussed in the community, but there is currently no official solution or workaround for obtaining session cookies through this API endpoint alone [reference](https://github.com/apache/superset/issues/13907). If you need to make authenticated API requests (such as to /api/v1/dashboard) that require a session cookie, you have two main options: 1. **Login via the Web UI:** Logging in through the Superset web interface will set the session cookie in your browser, which you can then use for subsequent API requests. 2. **Programmatically Obtain CSRF Token and Cookie:** Superset provides a dedicated API endpoint to obtain the CSRF token and the necessary cookie headers for API calls. You can find this endpoint by searching for 'csrf' in the Superset API documentation. This approach is used to programmatically get the CSRF token and the associated cookies required for authenticated requests [reference](https://github.com/apache/superset/issues/32315). **Summary:** - /v1/security/login returns JWT tokens, not session cookies. - Session cookies are only set via the web login flow. - For programmatic access, use the CSRF token endpoint to get the required cookies for API calls. If you need to automate dashboard access and bearer tokens are not working for your use case, using the CSRF token endpoint to obtain the necessary cookies is currently the best available method. There is no supported way to get a session cookie directly from /v1/security/login. <!-- Dosu Comment Footer --> *To reply, just mention my name [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/5a918f58-7941-425b-bc2e-cb4ff44064e0?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/5a918f58-7941-425b-bc2e-cb4ff44064e0?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/5a918f58-7941-425b-bc2e-cb4ff44064e0?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/5a918f58-7941-425b-bc2e-cb4ff44064e0?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/5a918f58-7941-425b-bc2e-cb4ff44064e0?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/5a918f58-7941-425b-bc2e-cb4ff44064e0?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/5a918f58-7941-425b-bc2e-cb4ff44064e0?feedback_type=other)</sup> [](https://go.dosu.dev/discord-bot) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/apache/superset/discussions/33585) GitHub link: https://github.com/apache/superset/discussions/33585#discussioncomment-13279706 ---- This is an automatically sent email for notifications@superset.apache.org. To unsubscribe, please send an email to: notifications-unsubscr...@superset.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For additional commands, e-mail: notifications-h...@superset.apache.org
