Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@pedroigor
Copy link
Contributor

Closes #43587

Copy link
Contributor

@stianst stianst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change itself looks good, but not sure if we should rather wait for 27 for this since it's a breaking change

@pedroigor
Copy link
Contributor Author

I'll keep this one on the radar and mark it for 27.

Copy link
Contributor

@ahus1 ahus1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read the following in the docs:

If have JSON files you are using to import back up users that include the totp field, you can safely remove this field from your files as it is no longer used.
Not doing that will cause failure during user import because the field is unrecognized.

Is the data in the fields actually used? Can we just ignore it from the representation when reading it instead using JSON Ignore?

I'd say this behavior where I need to update a JSON manually that I imported from a previous version is something we usually avoid.

Can you think of a softer migration path?

@pedroigor
Copy link
Contributor Author

pedroigor commented Nov 10, 2025

Is the data in the fields actually used? Can we just ignore it from the representation when reading it instead using JSON Ignore?

I'm not sure how much it is used by people but if you look at most of places where we are using it today, I don't see any argument for keeping it:

  • Adds noise to user representations. What does it mean setting otp to a user is it necessary to import/create/update users with OTP?
  • It is very specific to OTP and does not cover other credential types
  • It has been deprecated for several years

IMO, we should just remove it. Even if it is a breaking change and forces people to manually update their representations. Hopefully, we will have some versioning in the feature that allows us to push people towards using a new version rather than breaking things. But one day people will need to update, regardless ....

Can you think of a softer migration path?

As you suggested, I thought about ignoring unknown fields (not really keeping the field/getters/setters there). But we do validate the representation today, and I guess we want to continue doing so.

@pedroigor pedroigor added this to the 27.0.0 milestone Nov 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Remove deprecated org.keycloak.representations.idm.UserRepresentation#isTotp method

3 participants