[Building Sakai] lessons support for antisamy

[Hedrick Charles]

I misunderstood what the way the non-antisamy code works. I just checked it. I think it's sufficiently consistent with LOW to use it if antisamy is present but disabled, and the site has chosen checking.

On Apr 22, 2013, at 5:54:31 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:

> When you say you added support for antisamy I think you mean you added
> support for the new feature that allows tools to suggest different
> security scan levels for user entered content. If that assumption is
> wrong then please clarify and ignore the rest of this email.
> 
> I think your tool should just request the lowest level of safety for
> the scanner that is appropriate for your app. There should be no
> reason for you to need to know what the default scan level is.
> 
> So if you are dealing with something admins are entering and you want
> to trust them then call it like this:
> String processFormattedText(strFromBrowser, errorMessages, Level.NONE);
> 
> If you think they need to be checked some but can be trusted more
> (like an instructor):
> String processFormattedText(strFromBrowser, errorMessages, Level.LOW);
> 
> and if you know they need to checked for sure (and securely limited):
> String processFormattedText(strFromBrowser, errorMessages, Level.HIGH);
> 
> and finally, if you are not sure and/or you want to let the system admin decide:
> String processFormattedText(strFromBrowser, errorMessages, Level.DEFAULT);
> or
> String processFormattedText(strFromBrowser, errorMessages);
> 
> 
> As always, the system admin can configure their own high and low by
> overriding the antisamy definition files (and none requires no
> configuration as no scanning happens in that case). You might mention
> that admins should avoid restricting certain operations when using
> lessonbuilder but ultimately it is up to them to decide what level of
> security they want for their institution. I expect that 90% of cases
> will use the built in definitions and most people using their own are
> likely to reduce the restrictions.
> 
> In the cases where the Antisamy scanner is not used (and the legacy
> scanner is used), it is simply going to scan at the same level for low
> and high (which is roughly equivalent to a bit less secure than the
> default antisamy low setting). Therefore you should be safe in
> assuming that it won't strip out or restrict content which would be
> allowed in the default antisamy settings (again, no guarantee since
> the legacy scanner can also be customized on a per-installation basis,
> but this is rare so same qualification as above).
> 
> Does that help?
> -AZ
> 
> 
> On Mon, Apr 22, 2013 at 5:24 PM, Charles Hedrick <hedrick at rutgers.edu> wrote:
>> I've just added support of rantisamy. I need to get it in immediately, or 2.9.2 may cause unexpected results.
>> 
>> When dealing with user HTML, currently for instructors I do no filtering.
>> WIth antinomy I believe I should use LOW, although many sites will probably need to set it to NONE.
>> 
>> The problem is that I can't tell what default to use. I can tell whether we have antisamy code. I currently say that if we have the code I default to LOW. The problem is that we may have the code but it may be disabled. There is no API call to tell whether it's disabled.
>> 
>> What would you say to making useLegacyCleaner public? Otherwise the only thing I can think to do is to call it via introspection. I'm willing to do that, but I consider it ugly to call non-public methods in the kernel ,although I have the mechanics to do that set up.
>> 
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> 
> 
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile