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

Support for prepared statements and placeholders #45

Open
nvx opened this issue Nov 29, 2015 · 4 comments
Open

Support for prepared statements and placeholders #45

nvx opened this issue Nov 29, 2015 · 4 comments

Comments

@nvx
Copy link

nvx commented Nov 29, 2015

The current way of passing untrusted user input is via manually escaping and then forming the sql query with the escaped values.

This is prone to human error and could result in sql injection attacks being possible.

The ideal situation would be to add support for prepared statements using placeholders. Is there any technical limitation of the nginx engine preventing this?

@agentzh
Copy link
Contributor

agentzh commented Nov 29, 2015

@nvx There is no technical limitations on the nginx side except the lack of tagging support in the standard ngx_http_upstream_keepalive module (where we need to tag in-pool connections with their prepared statements). Well, patches welcome :)

@agentzh
Copy link
Contributor

agentzh commented Nov 29, 2015

@nvx Oh, please ignore the ngx_http_upstream_keepalive_module part in my previous comment. The ngx_postgres module implements its own connection pool anyway. So there's no issues here.

@nvx
Copy link
Author

nvx commented Nov 29, 2015

Ah interesting point. My comment on technical limitation was actually thinking on the configuration side if the nginx config parser was able to cope with vararg-like statements. I haven't done any work with nginx plugins themselves before, so wondered if that was a blocker to implementing this.

@agentzh
Copy link
Contributor

agentzh commented Nov 29, 2015

@nvx Yes, nginx directives can accept a variable number of arguments. This is not a problem.

I just hope that the user does not have to prepare the same statement upon every request if the Pg connection is reused via the pool. That is, we just have to prepare the statement once for every single Pg connection (yes, this is the real performance benefit of preparing a statement and then executing it over and over again). So tagging connections in pool somehow is important for such stateful treatment.

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

No branches or pull requests

2 participants