Power User

@mangeshp16 The original question is over two years old. Since version 1.42, you can enforce MFA at the tenant level (or the application level if you have the enterprise plan). This means that any user who logs in is required to have MFA. If they do not, they are redirected to a page where they can set it up.

There are other ways to accomplish this. You could build your own MFA page which would call the APIs directly. When a user logs in, you can check to see if they have any twoFactor methods available and if they don't, you can send them to this page.

@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 This is similar to any ElasticSearch schema changes. (That is, adding attributes is easy, changing data types and removing attributes is tougher.)

There's no particular guidance available.

For testing, you can set the index name using fusionauth-app.user-search-index.name. More here: https://fusionauth.io/docs/v1/tech/reference/configuration

Hope that helps. If you have more specific questions, feel free to ask.

Hmmm. I looked at the code path and can't see any reason that registrations would be omitted when reindexing, which would be one reason the search might fail.

• What version of FusionAuth are you running?
• What version of ES are you running?
• After reindex, if you search for a user with a registration (by something other than that nested search), is the registration data present?
• Any other searches fail?
• Any other troubleshooting steps you can share?
• Reindexing typically doesn't need to be done very often. Roughly how often are you reindexing (and why)?

Thanks!

@mart

Hmmm. Haven't seen this before.

https://www.jvt.me/posts/2020/08/16/globally-disable-tls-java-httpsurlconnection/ looks interesting.

The java client uses https://github.com/inversoft/restify/ under the covers, so maybe there's some setting in that library? The docs are sparse (some might say not there at all) but the code is reviewable.

Let us know what you find.

@mschmidt Ah, sorry for the confusion. Glad you solved the issue!

@ndiarmand Thanks, just saw this now. Filed a bug: https://github.com/FusionAuth/fusionauth-issues/issues/2275

@jacksontrevan Yes, this is unfortunately a limitation of cookies.

You could work around that by setting up a DNS alias to local.example.com (assuming FusionAuth is running remotely at auth.example.com).

You can usually set that up by googling for local host in /etc/hosts <platform> which turns up:

• https://www.hostinger.com/tutorials/how-to-edit-hosts-file-macos
• https://www.manageengine.com/network-monitoring/how-to/how-to-add-static-entry.html

@nico-ayala Makes sense. We have some documentation here: https://fusionauth.io/docs/v1/tech/identity-providers/google#custom-parameters

Though that is for setting up an OIDC provider in FusionAuth, it might be somewhat helpful.