On Wed, Apr 29, 2009 at 2:44 PM, Chris O'Connell <oconn...@gorillachicago.com> wrote: > I sympathize with your problem. Perhaps you could just build a set of sql > includes, each of which is the correct sql for a particular use case. Then, > rather than building the sql string in your code, you instead just pass a > parameter into iBatis that it can use to determine which is the correct sql > include to use. Then, you will be using ## for bind variables. > Now, if you have hundreds of these cases, or there is some complicated > algorithm that is build those 'where' clauses, then you might be out of > luck.
Guess I'm out of luck then, since we want to use this to filter many different queries using the same algorithm. And the query part of the filter is being build by our algorithm, so it's "safe" when we are able to use bind-variables for the userdata (the filter variables). > Your best bet in that case might be to write your own sql injection > cleaner for all input variables (not a bad idea in many cases, anyway, since > you already have to worry about cross site scripting, cross site request > forgery, css injections, etc. etc. :) ). > Chris Rather then writing a sql injection cleaner, I think our best option is to change the iBatis code so it can do what we want. Since the "only" change we need is parsing the query twice, first for the Simple Dynamic SQL and then for the parameters. Taking into account that the Simple Dynamic SQL that we write will be safe to use, since the user entered information is put in the query using bind-variables. Regards, Wessel van Norel
