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!

@dan no problem at all. Completely understand it's tough offering support without reviewing how we have things setup.

Appreciate you shooting that link over and will do some investigation on our end to see what might work best for us.

Thanks!

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.

@dwong

FusionAuth is API first, so this type of flow could be created using our API and custom integration code.

Roughly:

On tenant B, a user from tenant A logs in. Do a search for a user If found, do a registration and/or user create using API. The newly created user can now be logged in. As referenced above, you may have some interstitial pages that would be needed for password generation as the user passes from one tenant to another.

Another way to do this would be to reconsider how you are using tenants and applications. Depending on your business requirements, registering a user to a new application rather than a completely separate tenant removes a few steps from a workflow as described.

Reference documentation -> https://fusionauth.io/docs/v1/tech/apis/

Thanks,
Josh

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