V3 casl 561 query tags

[Amaneusz]

No description provided.

[cyberhead-pl]

why .let ? Maybe I'm old-fashioned, but it looks a little weird, as I understand it replaces if(tags != null), but I had to read it twice to understand :)

[Amaneusz]

you are totally right, this is not clear - will change

[xeus2001]

Please do not use object, I removed it everywhere. If this should be a singleton, use the following syntax:

@JsExport
class TagNormalizer private constructor() {
  companion object TagNormalizer_C {
    @JvmStatic
    @JsStatic
    fun foo() {}
  }
}

The reason are plenty of bugs in the JavaScript compiler/linker combination. Sadly, the compiler (for objects) automatically names the companion object, and this naming does not work very well, when used across different modules, because somehow the linker messes up naming. We need to open a ticket with Jetbrains about it, but I would first want to have a working code, then to show the issues in the working code, so they can simply checkout, compile and debug.

[Amaneusz]

done

[xeus2001]

This will fail for a=1, because in this case index will be 1

[Amaneusz]

Nice catch, fixed & tested

[xeus2001]

This is prone to SQL injections and ASCII zero injections. Values that are provided by the client, like tag-names, must only be used in prepared-statements! You can quote this alternatively, still, it may have a bad impact on performance, when it is executed multiple times, because it can't be cached by the query parser (very likely does not matter in this case, because tag queries will be slow anyway).

[Amaneusz]

Very well spotted again - fixed & tested.
Currently, all values from queries (as well as already persisted tags) are used via prepared statement

[xeus2001]

That does not work, it need to be something IS NULL, NULL is like NaN, any value compared against it will be false (well, not exactly, but it is good to remember it like this).

[Amaneusz]

👍 fixed

[xeus2001]

Again, this is prone to SQL and ASCII zero injections, because not correctly escaped (remember, tags that start with @ allow all unicode characters! For regular expression, we should review carefully, if there is no way of code execution or query manipulation.

[xeus2001]

All of this prone to SQL injections and ASCII zero attacks.

[Amaneusz]

Wrapped this in prepared statement as so:

private fun selectTagValue(tagQuery: TagQuery, castTo: PgType? = null): String {
    val tagKeyPlaceholder = placeholderForArg(tagQuery.name, PgType.STRING)
    return when (castTo) {
        null -> "$tagsAsJsonb->$tagKeyPlaceholder"
        PgType.STRING -> "$tagsAsJsonb->>$tagKeyPlaceholder"
        else -> "($tagsAsJsonb->$tagKeyPlaceholder)::${castTo.value}"
    }
}

The tag key will be wrapped as $N and replaced in prepared statement.
The tagsAsJsonb alone is safe:

companion object {
    private val tagsAsJsonb = "naksha_tags(${PgColumn.tags}, ${PgColumn.flags})"
}```

[xeus2001]

As this class is part of lib-models, and it is a public class, it must be exposed to javascript via @JsExport annotation.

[Amaneusz]

done

[xeus2001]

Pair is not exportable to JS, do we need to keep the method public? If not, just make it private or internal, this should solve the issue I would say. Otherwise, you can use kotlin.collections.Map.Entry or its implementation?

[Amaneusz]

internal should do the trick - changed