Wow, that's interesting. I haven't had the time to scour the new 1.4 docs
yet. Thanks Pierre, it's nice to have someone correct your work before you
have to 'find' the implemetation problems yourself.
I suppose that during migration I could write a 1.3 program to decode all the
data and place it into temporary tables and then run a 1.4 that would encode it
all back. Of course this requires recompiling all my programs unless I use a
custom encoder class which calls the actual encoding method.
Anyway, I've looked through the prepared statement specs and all and although I
know it takes care of apostrophes and quotes I haven't found any references to
that behavior at all. My only concern is that does it escape all non-alpha
numeric characters? With all the databases out there there are quite a few of
database specific escape characters that could be used in user input forms to
undermine the security of the application.
Can anyone shed a little light on this for me or let me know of a place that
has a concrete spec of what the prepared statement set methods are doing
exactly?
Thanks!
Matt
Quoting Pierre-Yves Saumont <[EMAIL PROTECTED]>:
> >Another alternative is to use the URLEncoder and URLDecoder classes.
> This
> >takes all non alpha-numeric characters not including periods and
> changes
> them
> >into their HTML equivalent. This would convert any possible character
> or
> >string that would cause a problem with databases such as escape
> characters
> and
> >such.
>
> Beware that this might not be portable. Default (and only available)
> encoding scheme until version 1.3 is on byte ASCII. In 1.4 beta 2,
> default
> has been changed to UTF8. So, data encoded with version 1.3 would have
> to be
> decoded in 1.4 specifying a non default scheme. However, such programs
> will
> not work with version 1.3, which make the switch from 1.3 to 1.4 very
> problematic. One possibility would be to test for Java version and act
> accordingly. Such a program would only compile under 1.4 but should run
> in
> 1.3. Sun is aware of this problem, but put it in the "ease of use"
> category,
> which makes me think it could really stay like this in final release.
> The
> reason is obviously that such encoding is not intended for persistent
> data
> and should not be used in that case. Once again, the secure solution
> is
> prepared statements.
>
> Pierre-Yves
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources:
> http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
