-
Notifications
You must be signed in to change notification settings - Fork 18
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
Sanitize parsing of kwargs to handle complex dbnames #40
Conversation
I've updated this PR now to include a better test case and fix the actual problem. Commit message has been amended to the following:
|
Thank you for contributing! Will look into this as soon as I find time. |
@Cito thanks much. I'm fairly certain that this is a correct solution - spent a ton of time fighting with it in our own code, and the addition to the tests of quotes and backslash should enable refactor, if necessary, in the future. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tylarb - this also looks like the proper solution to me. Thanks for providing the test as well. I have commented one minor issue only. Let me know if you want to fix it, otherwise I can do it after merging.
The escaping of quotes in kwargs was done incorrectly, leading to problems where kwargs or dbname included a single quote. This caused an exception, pg.InternalError if a database name like `funny copy"db'with\\quotes` was used: `missing "=" after "with\\\\quotes'" in connection info string` But only if kwargs were specified - otherwise, the dbname was passed safely to _connect() as a plain string without being modified. This commit addressed this problem by correcting the order in which escaping is done. The kwargs test is modified to ensure that the case of included escape characters and single quotes are covered. Co-authored-by: Tyler Ramer <tramer@pivotal.io> Co-authored-by: Jamie McAtamney <jmcatamney@pivotal.io>
@Cito commit is amended with your suggestion. |
We encounted a bug in escaping dbname and connection options in pygresql 5.1.2, which we submitted a patch for here: PyGreSQL/PyGreSQL#40 This has been merged, but it will take time to be added to a tagged release. For this reason, we have downloaded the source using this commit, PyGreSQL/PyGreSQL@b1e040e to install. Co-authored-by: Tyler Ramer <tramer@pivotal.io> Co-authored-by: Jamie McAtamney <jmcatamney@pivotal.io>
We encounted a bug in escaping dbname and connection options in pygresql 5.1.2, which we submitted a patch for here: PyGreSQL/PyGreSQL#40 This has been merged, but it will take time to be added to a tagged release. For this reason, we have downloaded the source using this commit, PyGreSQL/PyGreSQL@b1e040e to install. Co-authored-by: Tyler Ramer <tramer@pivotal.io> Co-authored-by: Jamie McAtamney <jmcatamney@pivotal.io>
When kwargs was made available in pgdb.connect(), rather than appending
the argument values to the "dbopt" paramater passed to _connect(), the
kwargs were joined to dbname, which has it's own parameter in _connect()
already.
Due to this design, a dbname containing a space caused problems, with
the dbname parameters becoming something like:
dbname=dbname with space -c option=optionvalue
This caused an exception, pg.InternalError if a database name like
funny copy"db'with\\quotes
was used:missing "=" after "with\\\\quotes'" in connection info string
But only if kwargs were specified - otherwise, the dbname was passed
safely to _connect() as a plain string without being modified.
This commit addressed this problem by not touching the specified dbname.
A dbname can be be added safely as the database arg of pgdb.connect(),
or as part of the dsn string, and opts from the dsn string or kwargs
will be added appropriately as well, utilizing the dbopt args in
_connect() rather than overloading the dbname.
Co-authored-by: Tyler Ramer tramer@pivotal.io
Co-authored-by: Jamie McAtamney jmcatamney@pivotal.io