Topics created by yves

@yves So I found this that may be of interest to you.

For the Authorization Code Grant, if the clientAuthenticationPolicy value is Required, the client secret is required. If the value is NotRequired, the client secret is not required. If the value is NotRequiredWhenUsingPKCE and PKCE is used, the client secret is not required. If PKCE is not used, the client secret is required.

What is your setting there?

@yves

I guess I'm struggling to understand how FusionAuth internally saves the user data. Is this unstructured (e.g. JSON) inside the relational database?

You can examine the database schema FusionAuth uses here: https://fusionauth.io/docs/v1/tech/installation-guide/fusionauth-app#advanced-installation

I guess I can't give this more structure, e.g. defining data types, and so on?

The structure for the .data fields is implicit. This means that you can define the schema by creating a value. So if I set user.data.isPremium to true, then ES will understand that user.data.isPremium is of type boolean.

A couple of notes:

if you change the datatype across users, ES will get confused. Here's docs on how to deal with that: https://fusionauth.io/docs/v1/tech/admin-guide/troubleshooting#mapperparsingexception there's an open issue for allowing schema enforcement. Please upvote it or add other feedback using the PATCH method for arrays in the user.data field is a bit fragile. Here's docs on how to choose this method correctly: https://fusionauth.io/docs/v1/tech/apis/#the-patch-http-method

I guess there's also no "direct" access to the user data via an API? At least I didn't find anything.

You can update, patch or remove values from the user.data field using the normal user APIs. Or did I misunderstand your question?

@yves

I'd be interested to see if the same issue occurs on the latest version of FusionAuth. There's 4-5 mentions of Elasticsearch in the release notes between 1.34.0 and 1.45.3, but none of them appear to address what you are seeing.

As mentioned above, also searching directly via id for example fails.

Sorry, I missed that. Are you saying when you search using the ids method (described here under the heading Search for Users by Id) it doesn't find these users? Because that search should go directly to the database and not through ES at all.

It's all a bit suboptimal.

Off topic, but please consider adding your voice to this issue which might help with your schema changes.