surawut-jirasaktavee opened a new issue, #45898: URL: https://github.com/apache/superset/issues/45898
### Bug description The column-values cache (filter dropdown values) uses the same key for every user with the same row-level security. It ignores the per-user cache settings that chart data honors: the `CACHE_QUERY_BY_USER` and `CACHE_IMPERSONATION` feature flags and the database's `per_user_caching` extra. This affects datasets and semantic views. When the database or semantic layer returns rows that depend on the user, one user can see another user's cached distinct values. Related: #45877 (the same gap in the chart-data result cache for semantic views). #### How to reproduce Environment: Superset master, a shared data cache (for example, Redis), `CACHE_QUERY_BY_USER: True`. A dataset on a database with user impersonation enabled, where the upstream engine filters rows per user. 1. User A opens a native filter (or an Explore filter popover) on a column. A sees the values A is allowed to see. 2. User B, who is allowed to see different rows, opens the same filter. B sees A's values, served from the cache. The same happens for semantic views whose provider returns results that depend on the querying user. #### Expected results When per-user caching is enabled, each user gets their own column-values cache entry, as for chart data. #### Actual results All users with the same row-level security share one column-values cache entry per column and query. #### Root cause (refs at e33b7d9fe3) 1. `_column_values_cache_key` builds the key from the query, datasource UID, RLS, `changed_on`, rendered/inner RLS and, for semantic views, the metadata generation. It never calls `add_impersonation_cache_key_if_needed`, so no per-user material is added ([superset/datasource/api.py#L91-L118](https://github.com/apache/superset/blob/e33b7d9fe3f61cba381f8c9de2cf724f1bb968eb/superset/datasource/api.py#L91-L118)). The docstring of `get_cached_column_values` says entries are partitioned by effective RLS "not by user" ([#L141](https://github.com/apache/superset/blob/e33b7d9fe3f61cba381f8c9de2cf724f1bb968eb/superset/datasource/api.py#L141)). 2. Chart data adds the per-user key through `add_impersonation_cache_key_if_needed` ([superset/utils/cache_keys.py#L33-L54](https://github.com/apache/superset/blob/e33b7d9fe3f61cba381f8c9de2cf724f1bb968eb/superset/utils/cache_keys.py#L33-L54)), but dataset values run through the same per-user engine without it ([superset/models/helpers.py#L6060](https://github.com/apache/superset/blob/e33b7d9fe3f61cba381f8c9de2cf724f1bb968eb/superset/models/helpers.py#L6060)). 3. The same key is used by the column-values endpoint (`/api/v1/datasource/<type>/<id>/column/<column>/values/`) and by MCP dashboard-filter validation ([superset/mcp_service/dashboard/tool/apply_dashboard_filters.py#L214](https://github.com/apache/superset/blob/e33b7d9fe3f61cba381f8c9de2cf724f1bb968eb/superset/mcp_service/dashboard/tool/apply_dashboard_filters.py#L214)). Samples and drill-to-detail go through the chart-data cache key, so they are not affected by this gap. #### Possible fix Add per-user material to `_column_values_cache_key` only when per-user caching applies, so keys stay byte-identical for existing deployments: - Datasets: call `add_impersonation_cache_key_if_needed(datasource.database, material)`, same as chart data. - Semantic views: reuse the per-user partition from the #45877 fix. ### Screenshots/recordings _No response_ ### Superset version master / latest-dev ### Python version 3.11 ### Node version Not applicable ### Browser Chrome ### Additional context Found by code reading while working on #45877; the steps above follow from the code and have not been reproduced end to end. I'm working on a fix for this myself and will open a PR. ### Checklist - [x] I have searched Superset docs and Slack and didn't find a solution to my problem. - [x] 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
