cfml

Any easy alternate of isSafeHTML function in Lucee?

it is relatively easy to get antisamy to work in lucee, i imagine isSafeHtml() is similar to to calling scan() and then checking if getNumberOfErrors() == 0

There are also anitsami wrappers for ColdBox which wrap the same java lib
<https://forgebox.io/view/cbantisamy>

<https://docs.lucee.org/reference/functions/sanitizehtml.html>

fun fact, you know how these decision functions work? isJson for example, does a
```try
{
   deserializeJson(json);
   return true;
} catch (e){ 
  return false;
}```
the traditional approach of checking isJson then deserializing, usually end up parsing the json twice!!!

<@U070SQMD1>,

As I just added some `isJSON()` safety checks due to the change in behavior of `deserializeJSON()` not working with empty strings in Lucee 6, your comment on how `isJSON()` works made me go look at the code.

The code is at least shortcutting the logic if the string is empty to return `false` (which makes it fast in my use cases), but I wonder if there would be a significant speed difference on larger strings if there was at least a safety check that the first and last characters at least appear valid.

I wonder if updating the `IsJSON.java` 's `call` method with a check like the following would help performance on large strings:

```String str = Caster.toString(obj, null);
String trimmed = str.trim();
char first = trimmed.charAt(0);
char last = trimmed.charAt(trimmed.length() - 1);

if(
        StringUtil.isEmpty(trimmed)
    ||
        // sanity check strings
        (first == '"' && last != '"')
    ||
        // sanity check objects
        (first == '{' && last != '}')
    ||
        // sanity check arrays
        (first == '[' && last != ']')
    ||
        // sanity check numbers
        ((Character.isDigit(first) || first == '-') && !Character.isDigit(last))
) return false;
// sanity check keywords
else if (
    trimmed.equals("true") || trimmed.equals("false") || trimmed.equals("null")
) return true;```
Just something to quickly sanitize before parsing.

I'll try to do some playing with this. I have one last day to play with Lucee 6 compatibility with our application, and I think I'll have some time to squeeze this in.

ahhhh, i love these kind of responses!!! which ticket it the empty strings one?

by default the lucee json parser (it's actual just the cfscript parser in strict mode) is lenient and allows json5, which means there can be leading comments, i really do like the idea of short circuiting parsing large files, as they aren't cheap

there's a comments function in the cfmlparser which strips them off, tho once you dive into that code, you'll see a lot of german comments
<https://github.com/lucee/Lucee/blob/7.0/core/src/main/java/lucee/runtime/interpreter/CFMLExpressionInterpreter.java#L1570>