We currently don't document these. Probably should; I'll put it on the list.

Until then, you can find the indexed fields by querying elasticsearch:

curl -XGET http://elasticsearchhost:port/fusionauth_user/_mapping

This will return something like the below JSON. This will vary based on your FusionAuth installation, however:

"fusionauth_user": { "mappings": { "_source": { "enabled": false }, "properties": { "active": { "type": "boolean" }, "birthDate": { "type": "date" }, "breachedPasswordLastCheckedInstant": { "type": "long" }, "breachedPasswordStatus": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "data": { }, "email": { "type": "text", "analyzer": "exact_lower", "fielddata": true }, "fullName": { "type": "text", "fielddata": true }, "id": { "type": "keyword" }, "insertInstant": { "type": "date" }, "lastLoginInstant": { "type": "date" }, "lastUpdateInstant": { "type": "date" }, "login": { "type": "keyword" }, "memberships": { "type": "nested", "include_in_parent": true, "properties": { "data": { "type": "object" }, "groupId": { "type": "keyword" }, "id": { "type": "keyword" }, "insertInstant": { "type": "date" }, "userId": { "type": "keyword" } } }, "mobilePhone": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "preferredLanguages": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "registrations": { "type": "nested", "include_in_parent": true, "properties": { "applicationId": { "type": "keyword" }, "authenticationToken": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "data": { }, "id": { "type": "keyword" }, "insertInstant": { "type": "date" }, "lastLoginInstant": { "type": "date" }, "lastUpdateInstant": { "type": "date" }, "preferredLanguages": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "roles": { "type": "keyword" }, "tokens": { "properties": { "5ccff761-f809-49c7-a58c-27a3cb9ab650": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "84ef0274-70db-44da-8762-aa6bcfbd2981": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "Google": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } } } }, "username": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "usernameStatus": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "verified": { "type": "boolean" } } }, "tenantId": { "type": "keyword" }, "timezone": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "username": { "type": "text", "fielddata": true }, "verified": { "type": "boolean" } } } } }

You can use a 'soft delete'.

Whenever you delete a user with the API without using hardDelete=true, the user is not able to login, but will still be visible in the API and the management UI.

See https://fusionauth.io/docs/v1/tech/apis/users/#delete-a-user for more.

There is no feedback to the user.

Whether the account exists with that email or not, the default message indicates a message will be sent.

If the user does not exist with that email, no email is sent.

The reason to avoid returning an error is to limit the ability to enumerate the users in the system, generally considered a bad thing(TM).

I see patchUser here:

https://github.com/FusionAuth/fusionauth-java-client/blob/1.19.0/src/main/java/io/fusionauth/client/FusionAuthClient.java#L1664

I think that's what you want.

You can, however, always full retrieval and a put as a workaround. That is recommended if you are changing an array, unless you want the behavior documented here: https://github.com/FusionAuth/fusionauth-issues/issues/441

Is this what you are looking for?: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-and-registration-combined

That API does return a token as of v1.17.0.

It means the user won't be able to login.

@dan Thank you for your support. Fixing the signature just saved me another couple of hours (also coming from https://fusionauth.io/blog/2020/07/14/django-and-oauth/) ^^

I totally forgot to add the register the user manually to the FusionAuth application. It is working now, thank you!

Currently, if you aren’t using federated login for your users and want to use FusionAuth’s OAuth system or Login API, you must migrate users over. More about migration here: https://fusionauth.io/docs/v1/tech/tutorials/migrate-users

We are working on supporting external userstores and it should be available soon.

You can experiment in the admin UI using the search field.

You can use the query string DSL or a full JSON query in the search field, if you are running elastic search.

Here's a link to building an ElasticSearch query (in version 6.3): https://www.elastic.co/guide/en/elasticsearch/reference/6.3/query-dsl-query-string-query.html

For example if you have companyName in custom data, the query string would be data.companyName:"Acme Corp."

If you are using the database search, you won't be able to use this kind of querying.

Here's more on the difference between the database search and elasticsearch options for user search: https://fusionauth.io/docs/v1/tech/core-concepts/users#user-search

You can search on the user id. While it doesn't say that in the placeholder, it works.

That is correct. Each user can have one email address, one username, or both. Either of these values can be used to login, and therefore the values are unique within the tenant.

We do have a username field on a registration, but it is not used for login.

There's a github issue open for multiple identities: https://github.com/fusionauth/fusionauth-issues/issues/1

No, but you can flush the index: https://fusionauth.io/docs/v1/tech/apis/users#flush-the-search-engine . From that doc:

This will cause any cached data to be written to disk.

@rnsupercool

Unfortunately, there's no way to extract the password and the other information via the APIs.

Options I could see working:

if you have developer edition (or other paid edition), you could set up a connector from FusionAuth to itself (via a generic http connector). This would take time to move the users to a different tenant. you can get a database dump of your FusionAuth instance and run a bulk import of the user data, password, and other password settings into another tenant. you could move over the users, set a random password and force them to change their password by setting passwordChangeRequired. Not sure that would definitely work; you should test this.

Hope this helps.

That message means the user is not registered for the application you’re logging into. If you create a registration for the user you’ll see Authenticated.

More on this here: https://fusionauth.io/community/forum/topic/5/can-you-limit-a-user-s-login-authentication-access-to-applications-within-a-single-tenant/2