Yes in the case of 2.5.5.Final it won't help but we can fix it there ourselves, since the version is "fixed". However for future versions if Keycloak it would be good to have a smoother upgrade process. I think in this case it is a trade-off between robustness and evolvability. If you want to make it easy for people to upgrade to newer Keycloak versions it would help to relax the handling of unknown fields a bit. The rest is a question of how the API is tested. A test suite can also discover problems such as broken request / response objects by verifying the outcome of an operation. Also one could argue that having typos in a structured request is not very likely - if the user users the libraries / structures provided by Keycloak, otherwise (JS...) they can happen of course.

But again users need to verify themselves via tests whether or not a request succeeds. Even if they have no typo in a field name but a wrong value the request would (should) still fail. Other options to deal with this would of course be to version the API, however having a full blown versioning mechanism that effectivly copies the whole REST interface would be very much overkill. A leaner approch could be to let the client tell the server which version of Keycloak they are compatible with via an Header. e.g.: x-keycloak-version: 2.5.5.Final The server REST infrastructure could then inspect that header and dynamically add Jackson Mixins for request / response messages to maintain compatibility - if this is possible / makes sense. E.g. Keycloak server could support basic operations for older clients, even with support for newer features by applying sane defaults. "New" fields (introduced after x-keycloak-version) would then just be excluded in the response.

Cheers, Thomas 2017-09-28 12:13 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com&gt;: > Would be good to have backwards compatibility, but: > > * Adding to reps wouldn't help for admin client 2.5.5, and we're not > doing a new release of the admin client for 2.5.x. > * Server side shouldn't ignore unknown fields as that could mask issues. > For instance a typing error would just result in ignoring rather than an > error. > > On 28 September 2017 at 10:11, Thomas Darimont < > thomas.darimont(a)googlemail.com&gt; wrote: > >> Hello, >> >> I just noticed that it isn't possible to create a user with the old >> keycloak admin client (2.5.5.Final) >> on the Keycloak Server (3.3.0.CR2). See the exception below. >> >> It turns out that the recently introduced field "notBefore" on >> UserRepresentation in KEYCLOAK-5293 is the cause. >> Other representations like ClientRepresentation (unknown field "access") >> and ProviderRepresentation (unknown field "order") >> have the same problem. >> >> How about adding... @JsonIgnoreProperties(ignoreUnknown = true) ... to >> all >> representations (org.keycloak.representations.idm.*) to stay backwards >> compatible for old clients? >> >> I gave this a spin locally (by patching the keycloak-core jar) and it is >> working fine. >> >> Cheers, >> Thomas >> >> >> javax.ws.rs.client.ResponseProcessingException: >> javax.ws.rs.ProcessingException: >> com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: >> Unrecognized field "notBefore" (class >> org.keycloak.representations.idm.UserRepresentation), not marked as >> ignorable (24 known properties: "disableableCredentialTypes", "enabled", >> "emailVerified", "origin", "self", "applicationRoles", >> "createdTimestamp", >> "clientRoles", "groups", "username", "totp", "id", "email", >> "federationLink", "serviceAccountClientId", "lastName", "clientConsents", >> "socialLinks", "realmRoles", "attributes", "firstName", "credentials", >> "requiredActions", "federatedIdentities"]) >> at [Source: org.apache.http.conn.EofSensorInputStream@2663e964; line: >> 1, >> column: 308] (through reference chain: >> java.util.ArrayList[0]->org.keycloak.representations.idm.Use >> rRepresentation["notBefore"]) >> at >> org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.ex >> tractResult(ClientInvocation.java:141) >> at >> org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.Bo >> dyEntityExtractor.extractEntity(BodyEntityExtractor.java:59) >> at >> org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker >> .invoke(ClientInvoker.java:104) >> at >> org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.i >> nvoke(ClientProxy.java:64) >> at com.sun.proxy.$Proxy32.search(Unknown Source) >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >