-
Notifications
You must be signed in to change notification settings - Fork 258
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
Parameterized queries #52
Comments
Hello! Let me see if I got it exactly: There should not be ambiguity around |
Technically it's the appearance of the raw character That initial query string isn't valid JSON, so the parse should be unambiguous. It's more complicated to track things like: |
That's cool, what would be an easy way to identify |
Closed w/ PR 53 |
Using tiedot in embedded mode, one often wants to create a query based on user input. There isn't really a safe / easy way to do this at the moment. Concatenating user-supplied strings could embed things that muck up your JSON (analogous to SQL injection). Substituting a string in your final marshaled JSON object requires you to write a decent amount of specific code & casts for each parameterization as you traverse what the compiler thinks is a
map[string]interface{}
.My preferred solution would be to have a function
EvalParameterizedQuery(q string, src *Col, result *map[uint64]struct{}, params ...string) (err error)
that interpolates?
to the parameters (considering them as strings) and then marshals the JSON internally. Since a raw?
embedded in JSON, without wrapping in a string, is a syntax error, this should be unambiguous.One would have to do quote-counting to identify the un-string-wrapped
?
's, mindful of the possibility of escaped"
characters.My understanding is that given you're able to identify the insertion point as valid, it's sufficient to wrap the user-supplied string in double-quotes and escape the characters:
If this is an acceptable solution, I'm willing to write this up (although it may take me some time).
The text was updated successfully, but these errors were encountered: