You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way these untyped Any values are constructed and interpreted is undocumented and unclear. The only way to actually know what they should be is to look into how they are serialized:
This implementation does at least two things which are presumably for "convenience" but are in fact completely undocumented and unexpected by the user:
A String is first attempted to be parsed as JSON, otherwise it is wrapped in a JSON string - this can lead to some tricky, unexpected behavior and nasty bugs if someone accidentally uses a literal string value which just happens to be a valid JSON (e.g. "[]").
Usage of .toString in the fallback case may leak data that the user never intended to be serialized - in the worst case this may cause nasty security issues
First of all, the decoder may return a value different than the one originally serialized, violating the "round-trip law" of serialization, i.e. decode(encode(something)) == something
In fact, exampleMultipleValueDecoder is completely useless, as exampleSingleValueDecoder never fails - therefore, an ExampleMultipleValue can never be deserialized
The decoder may return (wrap) a un-deserialized, Circe-specific Json value, which is quite bad because ExampleValue should be a model type independent of serialization layer
All these problems are very typical of code that takes shortcuts by using untyped representations and APIs like Any and .toString.
A more principled way to represent examples would be to use a serialization-library-agnostic JSON representation. This could be something as simple as a raw JSON string wrapper or possibly a minimalistic, ad-hoc JSON AST representation.
Solving this issue would likely require changes beyond sttp-apispec as tapir would most likely also be affected since it is the primary user of this library.
The text was updated successfully, but these errors were encountered:
Current Scala representation of OpenAPI example values is rather unprincipled:
The way these untyped
Any
values are constructed and interpreted is undocumented and unclear. The only way to actually know what they should be is to look into how they are serialized:This implementation does at least two things which are presumably for "convenience" but are in fact completely undocumented and unexpected by the user:
String
is first attempted to be parsed as JSON, otherwise it is wrapped in a JSON string - this can lead to some tricky, unexpected behavior and nasty bugs if someone accidentally uses a literal string value which just happens to be a valid JSON (e.g."[]"
)..toString
in the fallback case may leak data that the user never intended to be serialized - in the worst case this may cause nasty security issuesThe decoder is also not without problems:
decode(encode(something)) == something
exampleMultipleValueDecoder
is completely useless, asexampleSingleValueDecoder
never fails - therefore, anExampleMultipleValue
can never be deserializedJson
value, which is quite bad becauseExampleValue
should be a model type independent of serialization layerAll these problems are very typical of code that takes shortcuts by using untyped representations and APIs like
Any
and.toString
.A more principled way to represent examples would be to use a serialization-library-agnostic JSON representation. This could be something as simple as a raw JSON string wrapper or possibly a minimalistic, ad-hoc JSON AST representation.
Solving this issue would likely require changes beyond
sttp-apispec
astapir
would most likely also be affected since it is the primary user of this library.The text was updated successfully, but these errors were encountered: