Export variables should support other data types about cerbos

[haines]

I think changing the data type would be too confusing (e.g. if the list had string values, are those literals or CEL expressions?). I also agree it's probably not worth introducing another field. Shall we close this one as wontfix then?

[charithe]

Unfortunately, changing this is going to break existing deployments using a DB backend because the policies are stored in protobuf encoding and any data type change would make those policies undecodable.

[haines]

So, the map values would either be a constant value to be used directly as the value of the variable, or a CEL expression to evaluate to produce the value of the variable? How would we distinguish between a "raw" string and an expression?

At the moment we have definitions: map<string, string>, what if we just introduced an additional field constants: map<string, Value>, so that definitions contains CEL expressions and constants contains raw values?

[charithe]

So, this originally came up because someone asked how to define an array variable. The answer is to use a stringified representation (e.g. x: "[1,2,3]") and Cerbos converts it to an array at runtime because it evaluates the string as a CEL expression. That's what got me thinking whether we could change the data type from string to google.protobuf.Value and let users write "native" lists, maps etc.

I don't know whether introducing a constants field is worth it for fixing this minor annoyance. It might even confuse the users because they now have two options to pick from.