AntiSamy maxInputSize

696 views
Skip to first unread message

Austin

unread,
Jan 17, 2017, 7:46:49 PM1/17/17
to sakai-dev
Hello Devs,

Just wondering if anyone has increased the maxInputSize in their AntiSamy policy?

We've been seeing some errors our logs e.g.

"org.owasp.validator.html.ScanException: The input was too large. The specified input was 135,568 bytes and the maximum is 100,000 bytes."

We've seen between 5 and 125 of these errors per server (we're running 4 user facing servers) on any given day.  I don't think we've had any specific complaints from users about it, but since we see this error pretty often, I was wondering if it would be worth while increasing the maxInputSize.  also the rate of these errors seem to have increased since upgrading from 2.9.3 to 10.7

I saw some info on how to do this by placing a custom version of the policy in the tomcat/sakai directory:

http://stackoverflow.com/questions/24169695/how-do-i-modify-the-sakai-installations-antisamy-policy-files


Thanks,

Austin

Matthew Jones

unread,
Jan 18, 2017, 7:37:59 AM1/18/17
to Austin, sakai-dev
Yeah, we have increased it for a few clients, and in 11.2 the default is 1M. You can override it in earlier versions as described on that Stack Overflow.

The big reason this was changed it there's also a new word count plugin that will give the user an indication in the UI that they're going over the limit of characters.

Really the only way someone could type that many is if they pasted in a base64 encoded image or had a LOT of HTML formatting characters.

However even if you increase the size, it "could" lead to other issues and not all fields will allow 1M characters and increasing it too high will slow down the antisamy processing, but 1M seems fine. Some tools still have lower limits on their input fields and database columns so won't let you insert the content anyway and may or may not give you an error. Many of these database fields have been increased in newer versions of Saka. Like I know a bunch of field lengths were increased in Samigo in 11 (but I believe only to 60K) because Excel has another hard limit on how many characters it supports for exported fields.

So it's probably worth increasing it a little but it still seems like it's good to have some limit.

--
You received this message because you are subscribed to the Google Groups "Sakai Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-dev+...@apereo.org.
To post to this group, send email to saka...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/sakai-dev/.

Adam Marshall

unread,
Jan 18, 2017, 8:16:00 AM1/18/17
to Matthew Jones, Austin, sakai-dev

I believe there's a fix in 11.2 for this

Get Outlook for Android

Austin

unread,
Jan 18, 2017, 1:38:22 PM1/18/17
to Adam Marshall, Matthew Jones, sakai-dev
Thanks!  I'll take a look at those jiras and we'll try increasing that limit.

- Austin

On Wed, Jan 18, 2017 at 3:15 AM, Adam Marshall <adam.m...@it.ox.ac.uk> wrote:

I believe there's a fix in 11.2 for this

Get Outlook for Android

On Wed, Jan 18, 2017 at 12:38 PM +0000, "'Matthew Jones' via Sakai Development" <saka...@apereo.org> wrote:

Yeah, we have increased it for a few clients, and in 11.2 the default is 1M. You can override it in earlier versions as described on that Stack Overflow.

The big reason this was changed it there's also a new word count plugin that will give the user an indication in the UI that they're going over the limit of characters.

Really the only way someone could type that many is if they pasted in a base64 encoded image or had a LOT of HTML formatting characters.

However even if you increase the size, it "could" lead to other issues and not all fields will allow 1M characters and increasing it too high will slow down the antisamy processing, but 1M seems fine. Some tools still have lower limits on their input fields and database columns so won't let you insert the content anyway and may or may not give you an error. Many of these database fields have been increased in newer versions of Saka. Like I know a bunch of field lengths were increased in Samigo in 11 (but I believe only to 60K) because Excel has another hard limit on how many characters it supports for exported fields.

So it's probably worth increasing it a little but it still seems like it's good to have some limit.

On Tue, Jan 17, 2017 at 6:46 PM Austin <aust...@hawaii.edu> wrote:
Hello Devs,

Just wondering if anyone has increased the maxInputSize in their AntiSamy policy?

We've been seeing some errors our logs e.g.

"org.owasp.validator.html.ScanException: The input was too large. The specified input was 135,568 bytes and the maximum is 100,000 bytes."

We've seen between 5 and 125 of these errors per server (we're running 4 user facing servers) on any given day.  I don't think we've had any specific complaints from users about it, but since we see this error pretty often, I was wondering if it would be worth while increasing the maxInputSize.  also the rate of these errors seem to have increased since upgrading from 2.9.3 to 10.7

I saw some info on how to do this by placing a custom version of the policy in the tomcat/sakai directory:

http://stackoverflow.com/questions/24169695/how-do-i-modify-the-sakai-installations-antisamy-policy-files


Thanks,

Austin

--
You received this message because you are subscribed to the Google Groups "Sakai Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-dev+unsubscribe@apereo.org.

To post to this group, send email to saka...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/sakai-dev/.

--
You received this message because you are subscribed to the Google Groups "Sakai Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-dev+unsubscribe@apereo.org.
Reply all
Reply to author
Forward
0 new messages