In terms of 301, I do agree with you just in about 30% of your opinion there. But since we really need to finally make the API ready and compatible impl needs to be ready also upon the API release,
I am OK with dropping this 301 and 302…
David
Od: jsonb-dev <jsonb-dev-bounces@xxxxxxxxxxx>
za uživatele Romain Manni-Bucau
Odesláno: čtvrtek 9. prosince 2021 13:28
Komu: jsonb developer discussions <jsonb-dev@xxxxxxxxxxx>
Předmět: Re: [jsonb-dev] [External] : Refine polymorphic API
Hi Romain,
-
301
Yes, that is an issue, but I do not see the problem there if it is disabled by default and if allowed packages are required by the spec to be set. That’s exactly what the spec requires. In that case it is reasonably secure since it must be allowed by the user
explicitly. Impl should not load the class until it verifies that the class is in the allowed package.
RMB: verifying the package is not secured enough - and once again you can find it out there for backward compat reasons mainly. Being explicit or not does not help (unsecured=true will be the first thing you do if something prevents you
do more forward, right), so let's just drop it, will not prevent any use case the spec does not handle so no reason to add backdoors. Feel free to add some yasson property to complete the spec feature if you feel it is needed.
-
302
I will be honest here; I am not sure what API duplication are you talking about. I do not see anything wrong about adding this functionality. From my point of view, there is nothing wrong with having the format done over the enum.
Think one step further, format must not be an enum but a SPI so you define Format SPI....and get back to (de)serializer API so no need of that at all, it is a quick/fix design the spec does not need and shouldn't have to stay simple and
efficient instead of polluted by duplicated concepts (which tends to kill API when selected).
David
Hi all,
opened 2 issues we should tackle before next release on polymorphic topic:
Long story short we should ensure we are not dynamic at all on the types (301). This kind of behavior was introduced in existing (de)serialization libraries to mitigate the 0-day
issue but it is not a solution so let's stick to a clean design for our first release please.
The other issue (302) is mainly about not wanting to do too much at first release and opening the door to a design we'll regret in release N+1 since we will get back to another
duplication of API.
Overall our API should stick to:
|
@JsonbAnnotation
|
|
|
@Retention(RetentionPolicy.RUNTIME)
|
|
|
@Target({ElementType.ANNOTATION_TYPE,
ElementType.TYPE})
|
|
|
public
@interface
JsonbPolymorphicType {
|
|
|
|
|
|
/**
|
|
|
* Key used for keeping polymorphic information when {@link
Format#PROPERTY} is chosen.
|
|
|
* Default value is {@code
@type}.
|
|
|
*
|
|
|
*
@return
key name
|
|
|
*/
|
|
|
String key() default "";
|
|
|
|
|
|
/**
|
|
|
* Allowed aliases of the given polymorphic type.
|
|
|
*
|
|
|
*
@return
list of allowed aliases
|
|
|
*/
|
|
|
JsonbSubtype[] value() default {};
|
|
|
|
|
|
|
|
|
}
|
Overall it is way more important to ensure we can use (de)serializer in a portable manner to handle these requirements than addind and adding similar API which never cover all the
users requirements so let's stay robust and simple and work on real underlying issues (keep in mind we worked on that before (de)serializers behavior was not defined enough originally so it is not only syntaxic sugar because we didn't do our homework ;)).
_______________________________________________
jsonb-dev mailing list
jsonb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jsonb-dev
|
