You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by "baptisteaden (via GitHub)" <gi...@apache.org> on 2026/01/27 20:17:00 UTC
[D] Set database transaction params [superset]
GitHub user baptisteaden created a discussion: Set database transaction params
Hi!
**Question**
Is there any way to make Superset call something like `set local app.user_id = 'some_id';` in a transaction onto my database before a query runs so that the RLS in my database can read it?
**Context**
I'm using Superset `guest_token` and the embedded-sdk to show a dashboard in my web app. I'd like to make use of the RLS defined in my database rather than the Superset one because some rules are complex and would be very tedious/impossible to rewrite in Superset. For this, I'd need to set some parameters in the db before queries run (user_id, tenant_id, role). Obviously these values change depending on the logged user, so they should be stored in the guest_token I guess...
I searched everywhere but couldn't find an answer, and I'm a bit surprised because it doesn't seem like a very niche use case to be able to rely on database-level RLS. Is it doable? If not, is there a reason?
Thanks for your help!
GitHub link: https://github.com/apache/superset/discussions/37498
----
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] Set database transaction params [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
GitHub user dosubot[bot] edited a comment on the discussion: Set database transaction params
<!-- Greeting -->
Hi @baptisteaden! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the superset team.
<!-- Answer -->
Superset doesn't natively support running a dynamic SQL statement like `set local app.user_id = ...` before each query to set session variables for database-level RLS, especially in embedded or guest_token scenarios. There are a few hooks and workarounds, but each has limitations:
- You can use the SQL_QUERY_MUTATOR config hook to prepend SQL (like `set local ...`) to queries, but you'd need to implement logic to extract user context from the request/session, which is not straightforward with guest_token embedding. Also, this approach can get tricky with multi-statement queries and may not work seamlessly for all use cases or databases [(reference)](https://github.com/apache/superset/blob/master/superset/config.py).
- The DB_CONNECTION_MUTATOR hook lets you alter connection parameters per user/session, which works for things like impersonation or static session parameters, but it doesn't natively support injecting arbitrary per-query session variables from guest_token payloads [(reference)](https://github.com/apache/superset/blob/master/superset/config.py).
- Some database engine specs (like StarRocks) can run pre-session queries for impersonation, but this is database-specific and not a general solution for arbitrary session variables [(reference)](https://github.com/apache/superset/blob/master/superset/db_engine_specs/starrocks.py).
- For PostgreSQL, you can set static session parameters in the connection settings (e.g., `{"connect_args":{"options":"-c work_mem=32768"}}`), but these can't be set dynamically per user/session [(reference)](https://github.com/apache/superset/discussions/33879).
Currently, there is no built-in way to extract values from guest_token and inject them as session variables in the database connection for each query. If you need this, the closest workaround is a custom SQL_QUERY_MUTATOR, but integrating it with guest_token user context would require significant custom development.
Let me know if you want more details on any of these hooks or possible custom approaches.
<!-- 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).*
---
Docs are dead. Just use [Dosu](https://dosu.dev?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-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=static-docs-feedback&utm_term=apache%2Fsuperset&message_id=34bb42d3-bde8-4ace-84e2-982bd306019b) [](https://github.dosu.com/apache/superset?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-ask-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=static-docs-share-team&utm_term=apache%2Fsuperset)
GitHub link: https://github.com/apache/superset/discussions/37498#discussioncomment-15621552
----
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] Set database transaction params [superset]
Posted by "mergisi (via GitHub)" <gi...@apache.org>.
GitHub user mergisi added a comment to the discussion: Set database transaction params
Great question about implementing database-level RLS with session variables! This is a common challenge when working with embedded dashboards.
A few additional tips that might help:
1. **MUTATE_AFTER_SPLIT = True** is crucial when using `SET LOCAL` statements, as the mutator needs to run per-statement rather than on the whole query batch.
2. For PostgreSQL specifically, the `SET LOCAL` approach with `jwt.claims.*` is elegant because it's transaction-scoped - the variables automatically reset after each query, preventing any security leaks between requests.
3. If you're debugging why the mutator isn't called, try adding logging at the very start of your function and check Superset's worker logs (not just the web server logs).
4. An alternative approach I've seen work well: use database views with `current_setting('app.user_id')` in the WHERE clause, then your RLS logic lives entirely in the database layer.
For testing complex SQL patterns like these session variable injections, I often use [ai2sql.io](https://ai2sql.io) to quickly validate and generate the correct SQL syntax before implementing in the mutator - especially helpful when dealing with database-specific nuances between PostgreSQL, MySQL, etc.
Hope this helps! Let us know if you get it working.
GitHub link: https://github.com/apache/superset/discussions/37498#discussioncomment-15664185
----
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] Set database transaction params [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
GitHub user dosubot[bot] added a comment to the discussion: Set database transaction params
<!-- Greeting -->
Hi @baptisteaden! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the superset team.
<!-- Answer -->
Superset doesn't natively support running a dynamic SQL statement like `set local app.user_id = ...` before each query to set session variables for database-level RLS, especially in embedded or guest_token scenarios. There are a few hooks and workarounds, but each has limitations:
- You can use the SQL_QUERY_MUTATOR config hook to prepend SQL (like `set local ...`) to queries, but you'd need to implement logic to extract user context from the request/session, which is not straightforward with guest_token embedding. Also, this approach can get tricky with multi-statement queries and may not work seamlessly for all use cases or databases [(reference)](https://github.com/apache/superset/blob/master/superset/config.py).
- The DB_CONNECTION_MUTATOR hook lets you alter connection parameters per user/session, which works for things like impersonation or static session parameters, but it doesn't natively support injecting arbitrary per-query session variables from guest_token payloads [(reference)](https://github.com/apache/superset/blob/master/superset/config.py).
- Some database engine specs (like StarRocks) can run pre-session queries for impersonation, but this is database-specific and not a general solution for arbitrary session variables [(reference)](https://github.com/apache/superset/blob/master/superset/db_engine_specs/starrocks.py).
- For PostgreSQL, you can set static session parameters in the connection settings (e.g., `{"connect_args":{"options":"-c work_mem=32768"}}`), but these can't be set dynamically per user/session [(reference)](https://github.com/apache/superset/discussions/33879).
Currently, there is no built-in way to extract values from guest_token and inject them as session variables in the database connection for each query. If you need this, the closest workaround is a custom SQL_QUERY_MUTATOR, but integrating it with guest_token user context would require significant custom development.
Let me know if you want more details on any of these hooks or possible custom approaches.
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot).*
---
<sup>How did I do? [Good](https://app.dosu.dev/response-feedback/34bb42d3-bde8-4ace-84e2-982bd306019b?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/34bb42d3-bde8-4ace-84e2-982bd306019b?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/34bb42d3-bde8-4ace-84e2-982bd306019b?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/34bb42d3-bde8-4ace-84e2-982bd306019b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/34bb42d3-bde8-4ace-84e2-982bd306019b?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/34bb42d3-bde8-4ace-84e2-982bd306019b?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/34bb42d3-bde8-4ace-84e2-982bd306019b?feedback_type=other)</sup>
[](https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github) [](https://cursor.com/link/prompt?text=Superset%20doesn%27t%20natively%20support%20running%20a%20dynamic%20SQL%20statement%20like%20%60set%20local%20app.user_id%20%3D%20...%60%20before%20each%20query%20to%20set%20session%20variables%20for%20database-level%20RLS%2C%20especially%20in%20embedded%20or%20guest_token%20scenarios.%20There%20are%20a%20few%20hooks%20and%20workarounds%2C%20but%20each%20has%20limitations%3A%0A%0A-%20You%20can%20use%20the%20SQL_QUERY_MUTATOR%20config%20hook%20to%20prepend%20SQL%20%28like%20%60set%20local%20...%60%29%20to%20queries%2C%20but%20you%27d%20need%20to%20implement%20logic%20to%20extract%20user%20context%20from%20the%20request/session%2C%20which%20is%20not%20straightforward%20with%20guest_token%20embedding.%20Also%2C%20this%20approach%20can%20get%20tricky%20wi
th%20multi-statement%20queries%20and%20may%20not%20work%20seamlessly%20for%20all%20use%20cases%20or%20databases%20%5B%28reference%29%5D%28https%3A//github.com/apache/superset/blob/master/superset/config.py%29.%0A-%20The%20DB_CONNECTION_MUTATOR%20hook%20lets%20you%20alter%20connection%20parameters%20per%20user/session%2C%20which%20works%20for%20things%20like%20impersonation%20or%20static%20session%20parameters%2C%20but%20it%20doesn%27t%20natively%20support%20injecting%20arbitrary%20per-query%20session%20variables%20from%20guest_token%20payloads%20%5B%28reference%29%5D%28https%3A//github.com/apache/superset/blob/master/superset/config.py%29.%0A-%20Some%20database%20engine%20specs%20%28like%20StarRocks%29%20can%20run%20pre-session%20queries%20for%20impersonation%2C%20but%20this%20is%20database-specific%20and%20not%20a%20general%20solution%20for%20arbitrary%20session%20variables%20%5B%28reference%29%5D%28https%3A//github.com/apache/superset/blob/master/superset/db_engine_specs/starrocks
.py%29.%0A-%20For%20PostgreSQL%2C%20you%20can%20set%20static%20session%20parameters%20in%20the%20connection%20settings%20%28e.g.%2C%20%60%7B%22connect_args%22%3A%7B%22options%22%3A%22-c%20work_mem%3D32768%22%7D%7D%60%29%2C%20but%20these%20can%27t%20be%20set%20dynamically%20per%20user/session%20%5B%28reference%29%5D%28https%3A//github.com/apache/superset/discussions/33879%29.%0A%0ACurrently%2C%20there%20is%20no%20built-in%20way%20to%20extract%20values%20from%20guest_token%20and%20inject%20them%20as%20session%20variables%20in%20the%20database%20connection%20for%20each%20query.%20If%20you%20need%20this%2C%20the%20closest%20workaround%20is%20a%20custom%20SQL_QUERY_MUTATOR%2C%20but%20integrating%20it%20with%20guest_token%20user%20context%20would%20require%20significant%20custom%20development.%0A%0ALet%20me%20know%20if%20you%20want%20more%20details%20on%20any%20of%20these%20hooks%20or%20possible%20custom%20approaches.) [](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/37498)
GitHub link: https://github.com/apache/superset/discussions/37498#discussioncomment-15621552
----
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] Set database transaction params [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
GitHub user dosubot[bot] added a comment to the discussion: Set database transaction params
<!-- Answer -->
Your set_rls_context handler isn't being called because Superset v5 doesn't support a DB_ENGINE_MUTATOR hook that attaches SQLAlchemy event listeners like "begin" to the engine. The only supported engine mutator is DB_CONNECTION_MUTATOR, which is used to mutate connection parameters before engine creation—not to inject per-query or per-transaction logic. Superset's query execution flow doesn't wire in user-provided event listeners, so your approach won't trigger the handler as you expect ([reference](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/config.py#L1345-L1412)).
If you need to inject session variables per query (for RLS), the only viable path is to use SQL_QUERY_MUTATOR to prepend SET LOCAL statements to the SQL. However, integrating this with guest_token claims requires custom logic to extract those claims and inject them into the SQL string. There’s no built-in way to do this per user/session in embedded scenarios ([reference](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/config.py#L1345-L1412)).
Let me know if you want guidance on implementing a custom SQL_QUERY_MUTATOR for this use case.
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot).*
---
<sup>How did I do? [Good](https://app.dosu.dev/response-feedback/5aaf22c8-bb60-4dc3-bdc4-670c768f9c4c?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/5aaf22c8-bb60-4dc3-bdc4-670c768f9c4c?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/5aaf22c8-bb60-4dc3-bdc4-670c768f9c4c?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/5aaf22c8-bb60-4dc3-bdc4-670c768f9c4c?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/5aaf22c8-bb60-4dc3-bdc4-670c768f9c4c?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/5aaf22c8-bb60-4dc3-bdc4-670c768f9c4c?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/5aaf22c8-bb60-4dc3-bdc4-670c768f9c4c?feedback_type=other)</sup>
[](https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github) [](https://cursor.com/link/prompt?text=Your%20set_rls_context%20handler%20isn%27t%20being%20called%20because%20Superset%20v5%20doesn%27t%20support%20a%20DB_ENGINE_MUTATOR%20hook%20that%20attaches%20SQLAlchemy%20event%20listeners%20like%20%22begin%22%20to%20the%20engine.%20The%20only%20supported%20engine%20mutator%20is%20DB_CONNECTION_MUTATOR%2C%20which%20is%20used%20to%20mutate%20connection%20parameters%20before%20engine%20creation%E2%80%94not%20to%20inject%20per-query%20or%20per-transaction%20logic.%20Superset%27s%20query%20execution%20flow%20doesn%27t%20wire%20in%20user-provided%20event%20listeners%2C%20so%20your%20approach%20won%27t%20trigger%20the%20handler%20as%20you%20expect%20%28%5Breference%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/supe
rset/config.py%23L1345-L1412%29%29.%0A%0AIf%20you%20need%20to%20inject%20session%20variables%20per%20query%20%28for%20RLS%29%2C%20the%20only%20viable%20path%20is%20to%20use%20SQL_QUERY_MUTATOR%20to%20prepend%20SET%20LOCAL%20statements%20to%20the%20SQL.%20However%2C%20integrating%20this%20with%20guest_token%20claims%20requires%20custom%20logic%20to%20extract%20those%20claims%20and%20inject%20them%20into%20the%20SQL%20string.%20There%E2%80%99s%20no%20built-in%20way%20to%20do%20this%20per%20user/session%20in%20embedded%20scenarios%20%28%5Breference%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/config.py%23L1345-L1412%29%29.%20%0A%0ALet%20me%20know%20if%20you%20want%20guidance%20on%20implementing%20a%20custom%20SQL_QUERY_MUTATOR%20for%20this%20use%20case.) [](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/37498)
GitHub link: https://github.com/apache/superset/discussions/37498#discussioncomment-15641710
----
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] Set database transaction params [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
GitHub user dosubot[bot] edited a comment on the discussion: Set database transaction params
<!-- Answer -->
Your set_rls_context handler isn't being called because Superset v5 doesn't support a DB_ENGINE_MUTATOR hook that attaches SQLAlchemy event listeners like "begin" to the engine. The only supported engine mutator is DB_CONNECTION_MUTATOR, which is used to mutate connection parameters before engine creation—not to inject per-query or per-transaction logic. Superset's query execution flow doesn't wire in user-provided event listeners, so your approach won't trigger the handler as you expect ([reference](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/config.py#L1345-L1412)).
If you need to inject session variables per query (for RLS), the only viable path is to use SQL_QUERY_MUTATOR to prepend SET LOCAL statements to the SQL. However, integrating this with guest_token claims requires custom logic to extract those claims and inject them into the SQL string. There’s no built-in way to do this per user/session in embedded scenarios ([reference](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/config.py#L1345-L1412)).
Let me know if you want guidance on implementing a custom SQL_QUERY_MUTATOR for this use case.
<!-- 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=5aaf22c8-bb60-4dc3-bdc4-670c768f9c4c) [](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/37498#discussioncomment-15641710
----
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] Set database transaction params [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
GitHub user dosubot[bot] added a comment to the discussion: Set database transaction params
<!-- Answer -->
Your SQL_QUERY_MUTATOR should be called for every query in Superset v5, including embedded/guest_token scenarios, as long as it's correctly registered in your superset_config.py and Superset is restarted after changes. Here are some things to check:
1. Make sure SQL_QUERY_MUTATOR = sql_query_mutator is set in your superset_config.py (not just in a random Python file).
2. Restart all Superset processes (web server, Celery, etc.) after editing the config.
3. Test with a trivial mutator (e.g., always prepend "-- MUTATOR TEST\n" to every query) to confirm it's being called at all. If you don't see the comment in your database logs or Superset SQL logs, the config isn't loaded.
4. Check the MUTATE_AFTER_SPLIT setting: by default it's False, so the mutator runs on the whole query before splitting. If you want it to run per statement (which is usually needed for SET LOCAL), set MUTATE_AFTER_SPLIT = True in your config.
5. If the mutator is called but your logic isn't working, double-check that your guest claims are actually being set on Flask's g object before the query runs. The Flask request context and g are available when the mutator runs, so this approach should work if the claims are present.
If you want a more robust and future-proof solution for user-specific RLS with guest tokens, consider using the get_guest_user_attribute Jinja macro in your dataset SQL. This lets you pass user attributes in the guest token and reference them directly in your queries, without needing to mutate SQL or set session variables. Example:
```sql
SELECT * FROM your_table
WHERE user_id = '{{ get_guest_user_attribute("user_id") }}'
```
This approach is officially supported and works well for embedded dashboards with guest tokens.
If your mutator still isn't called after these steps, check for typos, config file location, or errors in the Superset logs. Let me know if you want a step-by-step for the Jinja macro approach or help debugging your config.
[Reference: SQL_QUERY_MUTATOR config and invocation](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/models/core.py#L408-L699)
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot).*
---
<sup>How did I do? [Good](https://app.dosu.dev/response-feedback/70fbc80c-978e-476d-aa9d-06cb96459841?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/70fbc80c-978e-476d-aa9d-06cb96459841?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/70fbc80c-978e-476d-aa9d-06cb96459841?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/70fbc80c-978e-476d-aa9d-06cb96459841?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/70fbc80c-978e-476d-aa9d-06cb96459841?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/70fbc80c-978e-476d-aa9d-06cb96459841?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/70fbc80c-978e-476d-aa9d-06cb96459841?feedback_type=other)</sup>
[](https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github) [](https://cursor.com/link/prompt?text=Your%20SQL_QUERY_MUTATOR%20should%20be%20called%20for%20every%20query%20in%20Superset%20v5%2C%20including%20embedded/guest_token%20scenarios%2C%20as%20long%20as%20it%27s%20correctly%20registered%20in%20your%20superset_config.py%20and%20Superset%20is%20restarted%20after%20changes.%20Here%20are%20some%20things%20to%20check%3A%0A%0A1.%20Make%20sure%20SQL_QUERY_MUTATOR%20%3D%20sql_query_mutator%20is%20set%20in%20your%20superset_config.py%20%28not%20just%20in%20a%20random%20Python%20file%29.%0A2.%20Restart%20all%20Superset%20processes%20%28web%20server%2C%20Celery%2C%20etc.%29%20after%20editing%20the%20config.%0A3.%20Test%20with%20a%20trivial%20mutator%20%28e.g.%2C%20always%20prepend%20%22--%20MUTATOR%20TEST%5Cn%22%20to%20every%20query%29%20to%20confirm%20
it%27s%20being%20called%20at%20all.%20If%20you%20don%27t%20see%20the%20comment%20in%20your%20database%20logs%20or%20Superset%20SQL%20logs%2C%20the%20config%20isn%27t%20loaded.%0A4.%20Check%20the%20MUTATE_AFTER_SPLIT%20setting%3A%20by%20default%20it%27s%20False%2C%20so%20the%20mutator%20runs%20on%20the%20whole%20query%20before%20splitting.%20If%20you%20want%20it%20to%20run%20per%20statement%20%28which%20is%20usually%20needed%20for%20SET%20LOCAL%29%2C%20set%20MUTATE_AFTER_SPLIT%20%3D%20True%20in%20your%20config.%0A5.%20If%20the%20mutator%20is%20called%20but%20your%20logic%20isn%27t%20working%2C%20double-check%20that%20your%20guest%20claims%20are%20actually%20being%20set%20on%20Flask%27s%20g%20object%20before%20the%20query%20runs.%20The%20Flask%20request%20context%20and%20g%20are%20available%20when%20the%20mutator%20runs%2C%20so%20this%20approach%20should%20work%20if%20the%20claims%20are%20present.%0A%0AIf%20you%20want%20a%20more%20robust%20and%20future-proof%20solution%20for%20user-sp
ecific%20RLS%20with%20guest%20tokens%2C%20consider%20using%20the%20get_guest_user_attribute%20Jinja%20macro%20in%20your%20dataset%20SQL.%20This%20lets%20you%20pass%20user%20attributes%20in%20the%20guest%20token%20and%20reference%20them%20directly%20in%20your%20queries%2C%20without%20needing%20to%20mutate%20SQL%20or%20set%20session%20variables.%20Example%3A%0A%0A%60%60%60sql%0ASELECT%20%2A%20FROM%20your_table%0AWHERE%20user_id%20%3D%20%27%7B%7B%20get_guest_user_attribute%28%22user_id%22%29%20%7D%7D%27%0A%60%60%60%0A%0AThis%20approach%20is%20officially%20supported%20and%20works%20well%20for%20embedded%20dashboards%20with%20guest%20tokens.%20%0A%0AIf%20your%20mutator%20still%20isn%27t%20called%20after%20these%20steps%2C%20check%20for%20typos%2C%20config%20file%20location%2C%20or%20errors%20in%20the%20Superset%20logs.%20Let%20me%20know%20if%20you%20want%20a%20step-by-step%20for%20the%20Jinja%20macro%20approach%20or%20help%20debugging%20your%20config.%20%0A%0A%5BReference%3A%20SQL_QUERY_
MUTATOR%20config%20and%20invocation%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/models/core.py%23L408-L699%29) [](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/37498)
GitHub link: https://github.com/apache/superset/discussions/37498#discussioncomment-15645416
----
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] Set database transaction params [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
GitHub user dosubot[bot] edited a comment on the discussion: Set database transaction params
<!-- Answer -->
Your SQL_QUERY_MUTATOR should be called for every query in Superset v5, including embedded/guest_token scenarios, as long as it's correctly registered in your superset_config.py and Superset is restarted after changes. Here are some things to check:
1. Make sure SQL_QUERY_MUTATOR = sql_query_mutator is set in your superset_config.py (not just in a random Python file).
2. Restart all Superset processes (web server, Celery, etc.) after editing the config.
3. Test with a trivial mutator (e.g., always prepend "-- MUTATOR TEST\n" to every query) to confirm it's being called at all. If you don't see the comment in your database logs or Superset SQL logs, the config isn't loaded.
4. Check the MUTATE_AFTER_SPLIT setting: by default it's False, so the mutator runs on the whole query before splitting. If you want it to run per statement (which is usually needed for SET LOCAL), set MUTATE_AFTER_SPLIT = True in your config.
5. If the mutator is called but your logic isn't working, double-check that your guest claims are actually being set on Flask's g object before the query runs. The Flask request context and g are available when the mutator runs, so this approach should work if the claims are present.
If you want a more robust and future-proof solution for user-specific RLS with guest tokens, consider using the get_guest_user_attribute Jinja macro in your dataset SQL. This lets you pass user attributes in the guest token and reference them directly in your queries, without needing to mutate SQL or set session variables. Example:
```sql
SELECT * FROM your_table
WHERE user_id = '{{ get_guest_user_attribute("user_id") }}'
```
This approach is officially supported and works well for embedded dashboards with guest tokens.
If your mutator still isn't called after these steps, check for typos, config file location, or errors in the Superset logs. Let me know if you want a step-by-step for the Jinja macro approach or help debugging your config.
[Reference: SQL_QUERY_MUTATOR config and invocation](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/models/core.py#L408-L699)
<!-- 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).*
---
Docs are dead. Just use [Dosu](https://dosu.dev?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-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=static-docs-feedback&utm_term=apache%2Fsuperset&message_id=70fbc80c-978e-476d-aa9d-06cb96459841) [](https://github.dosu.com/apache/superset?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-ask-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=static-docs-share-team&utm_term=apache%2Fsuperset)
GitHub link: https://github.com/apache/superset/discussions/37498#discussioncomment-15645416
----
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] Set database transaction params [superset]
Posted by "baptisteaden (via GitHub)" <gi...@apache.org>.
GitHub user baptisteaden added a comment to the discussion: Set database transaction params
@dosu Yes can you help with the SQL_QUERY_MUTATOR? I tried this but it's not called either:
```
def sql_query_mutator(sql, database, **kwargs):
print("🔥 RLS SET FROM G", flush=True)
if not has_request_context():
return sql
person_id = getattr(g, "app_person_id", None)
application_id = getattr(g, "app_application_id", None)
role = getattr(g, "app_role", None)
if not person_id:
return sql
# Escape values safely
def esc(val):
if val is None:
return "NULL"
return "'" + str(val).replace("'", "''") + "'"
rls_sql = f"""
SET LOCAL jwt.claims.person_id = {esc(person_id)};
SET LOCAL jwt.claims.application_id = {esc(application_id)};
SET LOCAL jwt.claims.role = {esc(role)};
"""
# Prepend RLS context before original query
return f"{rls_sql}\n{sql}"
SQL_QUERY_MUTATOR = sql_query_mutator
```
GitHub link: https://github.com/apache/superset/discussions/37498#discussioncomment-15645313
----
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] Set database transaction params [superset]
Posted by "baptisteaden (via GitHub)" <gi...@apache.org>.
GitHub user baptisteaden added a comment to the discussion: Set database transaction params
@dosu SQL_QUERY_MUTATOR was causing an error (maybe Superset version related? I'm on v5), I tried with DB_ENGINE_MUTATOR instead, something like that:
```
from superset.sql_parse import ParsedQuery
from flask_jwt_extended import get_jwt
from flask import has_request_context
class CustomSecurityManager(SupersetSecurityManager):
def get_guest_user_from_token(self, token):
user = super().get_guest_user_from_token(token)
custom = token.get("custom_claims", {})
g.app_person_id = custom.get("person_id")
g.app_application_id = custom.get("application_id")
g.app_role = custom.get("role")
print("🔥 Captured guest claims", custom, flush=True)
return user
CUSTOM_SECURITY_MANAGER = CustomSecurityManager
def db_engine_mutator(engine):
@event.listens_for(engine, "begin")
def set_rls_context(conn):
print("🔥 RLS SET FROM G", flush=True)
if not has_request_context():
return
person_id = getattr(g, "app_person_id", None)
application_id = getattr(g, "app_application_id", None)
role = getattr(g, "app_role", None)
if not person_id:
return
conn.exec_driver_sql(
"""
SET LOCAL jwt.claims.person_id = %s;
SET LOCAL jwt.claims.application_id = %s;
SET LOCAL jwt.claims.role = %s;
""",
(person_id, application_id, role),
)
return engine
DB_ENGINE_MUTATOR = db_engine_mutator
```
But it seems `set_rls_context` was never called as the log was never shown.
GitHub link: https://github.com/apache/superset/discussions/37498#discussioncomment-15641656
----
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