Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error in SQL editor with slashes in schema name #7236

Closed
3 tasks done
yciabaud opened this issue Apr 6, 2019 · 2 comments · Fixed by #7297
Closed
3 tasks done

Error in SQL editor with slashes in schema name #7236

yciabaud opened this issue Apr 6, 2019 · 2 comments · Fixed by #7297

Comments

@yciabaud
Copy link

yciabaud commented Apr 6, 2019

Make sure these boxes are checked before submitting your issue - thank you!

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

When using Superset with a PrestoDB database to connect Apache Pulsar SQL worker, errors are occurring when working with a schema containing slashes.

I am able to query data corectly but the UI is broken.

Sample query: select * from pulsar."public/default".generator_test limit 10;

Superset version

I am using Superset version 0.28.1 in Kubernetes using helm.

Expected results

I should be able to list tables from a schema containing slashes.

Actual results

An AJAX request is made to /superset/tables/2/public/default/undefined/ and finishes with status 404.
The UI displays an error message: Error while fetching table list

Steps to reproduce

  • Create a database with slashes in schema names (using pulsar for instance)
  • Add this database to Superset
  • Go to SQL editor and select a schema containing slashes in the select box
@villebro
Copy link
Member

villebro commented Apr 8, 2019

I was able to get this working, with slashes in both the table name and schema, but it was slightly more involved than I expected. The problem is that SQL Lab makes most calls with the parameters in the path, and for some reason escaped slashes (%2f) are converted to real slashes by most webservers (a security issue of some sort I believe). For table names this had been worked around by using the path: prefix in the Flask routing, but this doesn't work when there are multiple parameters with slashes (both table and schema in this case). A workaround I found for this was to perform escaping twice in the frontend (/ turns into %2f which turns into %252f), and then unescaping them twice in the backend. Anyway, I'll see if there's a better way to do this or clean up the code as much as possible and put in a PR when finished.

@yciabaud
Copy link
Author

OK thank you @villebro , let me know if you need some assistance from me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants