I am not a fan of Validator whatsoever. But, apart from that and I think a rules engine would already fit that bill. A rules engine would rest in your service layer. By the time your objects reach your DAO layer the assumption should be made that they are valid. If your validation issues can't be handled in your service layer then you should think about taking up stored procedures. Personally, I would not be on board with this kind of functionality in iBatis.
But, we have tossed around the idea of making iBatis 3.x configs more pluggable. Maybe you can take up the initiative then as a plugin. Brandon On 9/20/05, Brice Ruth <[EMAIL PROTECTED]> wrote: > Hi guys, > > I've been involved in various "secure application" efforts in the past > couple months and one idea that surfaced is securing database interaction > from the application that's accessing the database. So, basically preventing > parameters from being passed into the database that are invalid or crafted > in such a way as to expose vulnerabilities in the underlying database. > > Obviously SQL-injection is one such vulnerability, but this is easily > managed by using parameters. What I'm proposing is a validation framework > for iBATIS that works similarly to Struts Validator (and uses > Commons-Validator, as Struts does). So, in addition to having a SqlMap file, > you might have a validation file that could be configured by id or class > name (much like Struts allows an action path or an ActionForm to be > specified) - and the iBATIS infrastructure would run the incoming data > through the necessary validations, via commons-validator, before attempting > any database access. > > Obviously this is still a pretty rough idea, but it seemed like it had some > potential. What say ye? > > -- > Brice Ruth > Software Engineer, Madison WI
