[keycloak-user] [keycloak-dev] Incompatiblity of UserRepresentation (and other Reps) between 2.5.5.Final and 3.3.0.CR2

[Stian Thorgersen]

Adding list back..

On 28 September 2017 at 13:57, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> 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.
>

I'm thinking about the case when users don't use the libraries provided by
Keycloak, basically anyone not using Java (there's a few of them out there
you know ;)).


>
> 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.
>

We'll probably have to add versions for REST APIs regardless so it might be
better to just leverage that than to introduce yet another mechanism.


>
> Cheers,
> Thomas
>
> 2017-09-28 12:13 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> 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 at googlemail.com> 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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>