Custom serialization

[denis-sokolov]

This provides a capability for the clients to define custom serialization for their data, when standard JSON is not enough.

• Target branch temporary

[amclain]

With the client being able to write arbitrary encode and decode functions (if I read the code right), doesn't that open a potential attack vector? The most prominent vector I see is a malicious client being able to persist data that the server can't validate, which is then decoded by other legitimate clients. If this were used to overwrite IDs it could potentially be used as a form of permission escalation as well.

An alternative may be to whitelist a set of serializers on the server side that a client can choose from. This could still potentially involve custom serializers written outside of Oncilla, but the key is that the server is the authority for what serialization is supported.

[denis-sokolov]

I am very thankful you’re on the lookout, but I don’t think there is a vector here. The server does not execute arbitrary code passed in over HTTP, it would need an eval in there somewhere for that. The client has its own serializer, the server has its own.

[amclain]

I may be missing some context here and may not fully understand the architecture just from seeing this PR. That being said, is it a correct statement that the server will never transfer data to another client or persist any data it cannot understand (i.e. validate)? If that's the case, I'm fine.

[denis-sokolov]

I’m not sure I’m up-to-date. I’ve scheduled a call for us to cover this in more detail.