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

fix(#23176): adding URL decoding to SQLAlchemy URI #23421

Merged
merged 2 commits into from
Apr 6, 2023

Conversation

RekhaZemoso
Copy link
Contributor

@RekhaZemoso RekhaZemoso commented Mar 20, 2023

SUMMARY

Using urllib we can overcome this issue, now it is working fine

TESTING INSTRUCTIONS

set the superser config like
SQLALCHEMY_DATABASE_URI = "postgres://postgres:s3kr1t@localhost:5432/postgres?application_name=superset&options=--search_path%3D%22%24user%22,superset"

ADDITIONAL INFORMATION

@RekhaZemoso RekhaZemoso requested a review from a team as a code owner March 20, 2023 05:59
Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Congrats on making your first PR and thank you for contributing to Superset! 🎉 ❤️

We hope to see you in our Slack community too! Not signed up? Use our Slack App to self-register.

@rusackas
Copy link
Member

Looks sensible to me, and approving the CI workflows. Pinging a few folks for review here in case they know of any fragility around URI encoding/decoding that I'm unaware of.

@rusackas rusackas changed the title bug fix 23176 Fix #23176 by adding URL decoding Mar 20, 2023
@rusackas rusackas changed the title Fix #23176 by adding URL decoding fix(#23176): adding URL decoding to SQLAlchemy URI Mar 20, 2023
@codecov
Copy link

codecov bot commented Mar 20, 2023

Codecov Report

Merging #23421 (3d10830) into master (a5c31b2) will increase coverage by 0.07%.
The diff coverage is 62.01%.

❗ Current head 3d10830 differs from pull request most recent head a207bad. Consider uploading reports for the commit a207bad to get more accurate results

@@            Coverage Diff             @@
##           master   #23421      +/-   ##
==========================================
+ Coverage   67.62%   67.70%   +0.07%     
==========================================
  Files        1908     1918      +10     
  Lines       73682    74135     +453     
  Branches     7982     8052      +70     
==========================================
+ Hits        49828    50193     +365     
- Misses      21806    21889      +83     
- Partials     2048     2053       +5     
Flag Coverage Δ
hive 52.73% <ø> (-0.01%) ⬇️
mysql 78.51% <ø> (?)
postgres 78.59% <ø> (+0.07%) ⬆️
presto 52.66% <ø> (-0.01%) ⬇️
python 82.43% <ø> (+0.11%) ⬆️
sqlite 77.10% <ø> (+0.07%) ⬆️
unit 52.63% <ø> (+0.10%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...t-ui-chart-controls/src/shared-controls/mixins.tsx 16.66% <ø> (ø)
.../packages/superset-ui-core/src/chart/types/Base.ts 100.00% <ø> (ø)
...s/superset-ui-core/src/components/SafeMarkdown.tsx 66.66% <ø> (ø)
...ackages/superset-ui-core/src/query/types/Filter.ts 100.00% <ø> (ø)
...ackages/superset-ui-core/src/utils/featureFlags.ts 100.00% <ø> (ø)
...plugins/legacy-plugin-chart-heatmap/src/Heatmap.js 0.00% <0.00%> (ø)
...gins/legacy-plugin-chart-world-map/src/WorldMap.js 0.00% <0.00%> (ø)
...plugins/legacy-plugin-chart-world-map/src/index.js 66.66% <ø> (ø)
...tend/plugins/legacy-preset-chart-nvd3/src/utils.js 15.92% <ø> (ø)
.../plugins/plugin-chart-echarts/src/BoxPlot/index.ts 50.00% <ø> (ø)
... and 189 more

... and 88 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

superset/migrations/env.py Outdated Show resolved Hide resolved
@rusackas
Copy link
Member

rusackas commented Apr 6, 2023

Looks like the linters weren't happy with the import order. I committed a fix, and hopefully CI will pass now. Nag me for a merge or further fixes either way. Thanks for the fix!!!

@rusackas rusackas merged commit 8f03280 into apache:master Apr 6, 2023
@horkyada
Copy link

horkyada commented May 8, 2024

Hey, unfortunately this breaks other stuff, if I have a special character (e.g. '@') in password I need to escape it in order to work, but this effectively reverts my encoding back and then it fails because user:pass@word@host is invalid (see this #10483 (comment)). So if I don't escape, superset cannot connect to DB, if I escape, migrations fail. Any idea for workaround?

@rusackas
Copy link
Member

rusackas commented May 9, 2024

At risk of stating the obvious, changing the password is one workaround, though certainly not the workaround you're hoping for (sorry) :)

@villebro
Copy link
Member

villebro commented Oct 5, 2024

I agree with @horkyada on this - this breaks connection strings with special characters, and is IMO not the correct solution to the problem: unquoting the connection string will introduce : and @ and other special characters from the username and password, which will obviously break the connection string. I'm not sure how to get around the issue that's stated in the description, but I assume it's a much less common than having a password with special characters. Therefore I recommend reverting this - I'll follow up with a PR once I validate the new approach (I'll also try to address the issue in this PR while I'm at it)

FYI @rusackas @dpgaspar

@villebro
Copy link
Member

villebro commented Oct 7, 2024

FYI, follow up PR merged: #30532

@boraxpr
Copy link

boraxpr commented Oct 17, 2024

Hey, unfortunately this breaks other stuff, if I have a special character (e.g. '@') in password I need to escape it in order to work, but this effectively reverts my encoding back and then it fails because user:pass@word@host is invalid (see this #10483 (comment)). So if I don't escape, superset cannot connect to DB, if I escape, migrations fail. Any idea for workaround?

For anyone facing the same problem, I tried multiple combinations such as

p%40ssword%40hostname
p%2540ssword@hostname
p%2540ssword%40hostname

I thought %2540 might cause unquote to first convert %25 to % and %40 will then be convert to @. I was wrong because the password was treated as %40 literally, without a conversion, leading authentication failure.

The best solution I've found is to use password without any special characters. Reverting to 2.1.0 does not help, as that version -- despite not containing the unquote function, it has invalid interpolation syntax issue. And doubling percentage/%2540 do not work in 2.1.0 either, because the password will be taken as %40 literally, resulting in authentication failure.

@villebro
Copy link
Member

villebro commented Oct 17, 2024

FYI this regression should now be fully fixed on master branch, and has been cherry picked into the forthcoming 4.1.0 release.

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

Successfully merging this pull request may close these issues.

6 participants