GitHub user PiXOT97 created a discussion: Overcoming URL length limits when
using url_param Jinja injection in Embedded SDK
# Overcoming URL length limits when using `url_param` Jinja injection for
massive filter lists in Embedded SDK
## The Setup
We are using the **`superset-embedded-sdk`** to embed dashboards into our
application. We rely heavily on **Custom SQL Datasets** that utilize **Jinja
templating** to inject context-aware filters dynamically.
Our datasets typically look like this:
```sql
SELECT *
FROM massive_table
WHERE id IN ( {{ url_param('INJECT_FILTERS') }} )
-- Complex logic using these IDs follows...
We pass these filters via the Embedded SDK's fetch request, which results in a
GET request like:
bash
Copy code
GET /embedded/<uuid>?INJECT_FILTERS='id1','id2','id3',...
```
## The Problem
We are hitting hard URL length limits (HTTP 414).
Our internal IDs are long (~27 chars). When we need to inject a context with
500+ IDs, the URL exceeds 8KB–16KB, causing failures at the browser, NGINX
ingress, or cloud load balancer level.
## Constraints (Why we can't use standard solutions)
Cannot use Guest Token RLS
We have hundreds of existing datasets with complex Jinja logic (conditional
joins, dynamic subqueries) that cannot be expressed by the rigid, appended
WHERE clause provided by Guest Token RLS rules.
## Embedded SDK limits
The SDK initializes the iframe via src="...", which forces a GET request. We
cannot easily switch to POST to move the payload into the body.
## The Question
Has anyone successfully implemented a pattern to "hydrate" the url_param Jinja
context from a server-side source or a secondary POST request to bypass URL
limits?
I am considering implementing a Server-Side State pattern:
Backend stores the massive ID list in Redis and generates a UUID key.
Backend passes ?INJECT_FILTERS=key:uuid-123 in the URL (keeping it short).
In superset_config.py, I overload JINJA_CONTEXT_ADDONS with a custom url_param
function that intercepts this key, looks up the payload in Redis, and injects
the full list into the SQL.
Is this a recommended pattern? Or is there a native feature/hook in Superset
(perhaps related to Permalinks or form_data caching) that allows us to pass
massive context to the Jinja engine without bloating the URL?
GitHub link: https://github.com/apache/superset/discussions/37132
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
