ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DelGurth <delgu...@gmail.com>
Subject Re: Using #PARAM# constructions within $DYNAMICSQL$
Date Wed, 29 Apr 2009 13:05:14 GMT
On Wed, Apr 29, 2009 at 2:44 PM, Chris O'Connell
<oconnell@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.

Wessel van Norel

View raw message