[owasp-antisamy] A couple of questions about upgrading

Kristian Rosenvold kristian.rosenvold at gmail.com
Mon Mar 4 16:08:54 UTC 2013


The antisamy api is defined in terms of java strings. String instances in java
do not have a choice of encoding like arrays of bytes or streams.

When using a string based API it should be the responsibility of the creator of
the string to apply the correct encoding both in and out. Creating
java.lang.String
objects that contain byte data of any encoding other than the correct
internal unicode
representation is a disaster waiting to happen.

So that's why I removed them. If there really is some use case that would
make this a bad decision, do let me know. I'm always eager to learn!

I may have seen extra spaces creeping into empty tags at the end, I
would suspect the nekohtml version. Does changing nekohtml to 1.9.12
version help ?

 Kristian

2013/3/1 Jacob Coulter <jacob.coulter at gmail.com>:
> We have a factory that creates an Antisamy (v 1.4.1) and were hoping
> to upgrade to 1.5.1.  What happened to Antisamy.java's inputEncoding
> and outputEncoding? How do we set the equivalent values to manage
> these concerns now?
>
> Also, in several of our unit tests we are suddenly getting extra
> spaces wherever we have nested tags.  For instance, after scanning the
> string:  '<select name="name"><option
> value="Something">Something</select>'  We now get : '<select
> name="name"> <option value="Something">Something </select>'   Note the
> 2 extra spaces between the tags and before the closing select.  (The
> lack of closing option tag is not a pertinent part of this example.)
>
> The second issue doesn't seem to be causing pain, but it is
> unexpected.  Anyone else notice this?
>
> Thanks,
>
>   Jacob
> _______________________________________________
> Owasp-antisamy mailing list
> Owasp-antisamy at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-antisamy


More information about the Owasp-antisamy mailing list