Custom delimiter configuration isn't loaded for CSV import

[aho-exerp]

On 'CSV to Database configuration' the field for custom delimiter configuration isn't loaded when choosing 'Other' - due to violation of Content Security Policy (CSP) by static nonce on script. The issue isn't present the first time the page is loaded, but upon every following visit to the page.

How to reproduce the bug

1. Leave Superset with default TALISMAN configuration
2. Add database connection and under 'Advances'->'Security' check 'Allow file uploads to database'
3. In browser open development tools, so you can see the source HTML
4. Go to 'Data' -> 'Upload CSV to database'
5. Select on Delimiter: 'Other'
6. If you are opening this page first time, reload the page to see the error

Expected results

A free text input field under 'Enter a delimiter for this data' is loaded. No CSP errors.

Actual results

No text input field is loaded, instead in the Dev console of the browser you can see the following error:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'strict-dynamic' 'nonce-A3G08VMJ0tosJ5Wlse9kLCHiqfipHohf'". Either the 'unsafe-inline' keyword, a hash ('sha256-LDZ4ztcGb3PpryC0w3Ox6TyZleJKsSIt1Vu4Zay22rE='), or a nonce ('nonce-...') is required to enable inline execution.

Screenshots

In the html script one can see that the nonce set on the script handling the delimiter does not refresh along with the other nonces on the page when the page is refreshed but instead stays static.

Environment

(please complete the following information):

• browser type and version: Chrome 119.0.6045.200
• superset version: 3.0.1
• python version: 3.9.18
• node.js version: node -v
• any feature flags active:{ "ALLOW_DASHBOARD_DOMAIN_SHARDING": true, "CLIENT_CACHE": false, "DISABLE_DATASET_SOURCE_EDIT": false, "DYNAMIC_PLUGINS": false, "ENABLE_EXPLORE_JSON_CSRF_PROTECTION": false, "ENABLE_TEMPLATE_PROCESSING": false, "KV_STORE": false, "PRESTO_EXPAND_DATA": false, "THUMBNAILS": false, "DASHBOARD_CACHE": false, "REMOVE_SLICE_LEVEL_LABEL_COLORS": false, "SHARE_QUERIES_VIA_KV_STORE": false, "SIP_38_VIZ_REARCHITECTURE": false, "TAGGING_SYSTEM": false, "SQLLAB_BACKEND_PERSISTENCE": false, "LISTVIEWS_DEFAULT_CARD_VIEW": false, "DRILL_TO_DETAIL": true, "ENABLE_REACT_CRUD_VIEWS": true, "DISPLAY_MARKDOWN_HTML": true, "ESCAPE_MARKDOWN_HTML": false, "DASHBOARD_NATIVE_FILTERS": true, "GLOBAL_ASYNC_QUERIES": false, "VERSIONED_EXPORT": true, "ROW_LEVEL_SECURITY": false, "ALERT_REPORTS": true }

Checklist

Make sure to follow these steps before submitting your issue - thank you!

• [x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
• [x] I have reproduced the issue with at least the latest released version of superset.
• [x] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context

Add any other context about the problem here.

• Using TALISMAN_ENABLED = False negates the issue.
• Opening the page in another browser or incognito mode shows that the element presents the same static nonce.
• Adding 'unsafe-inline' to 'script-src' isn't a solution as it is ignored due to the nonce being present.

[rusackas]

I assume you're still facing this in Superset 3.1 / 4.x as we haven't changed much in Talisman configs.

Are you able to add unsafe-inline to script-src to work around this? CC @michael-s-molina @kgabryje who might know more about the nonce implementation.

[muh79]

This is coming a bit late but I found a fix.

Instead of using the usual import you can use a similar Jinja macro inside the template like this:

{% with nonce=csp_nonce() %} {% include 'superset/form_view/database_schemas_selector.html' %} {% endwith %}

Which ensures that the nonces it sets is the same one as of all the other scripts that are inside the template and didn't need to be imported.