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" } } } } }

@marcasellkhelaifi,

Glad that you got this figured out! Thanks for sharing!

Thanks,
Josh

This issue, in my opinion, has been resolved in this thread : https://fusionauth.io/community/forum/topic/1086/how-may-i-see-the-name-of-database-created-used-by-fusionauth-in-local-mysql?_=1623774571813.

If anyone has the same issue, I hope it will be helpful. Thank you.

You have a couple of options.

If you are self hosting, use a WAF, CDN or firewall to rate limit access to FusionAuth.

If you are using FusionAuth Cloud, we have protection in place to ensure customers don’t get DDoSed; additionally, all customer servers are monitored for responsiveness and availability.

If you need more rate limiting options, we're working on it: https://github.com/FusionAuth/fusionauth-issues/issues/905

If you need to preserve passwords, and you have access to the database:

You could manually read from the db and then import users using the import API. https://fusionauth.io/docs/v1/tech/apis/users/#import-users You can use pg_dump or mysqldump respectively if you want to move the entire system from one server to another, users and all. The target system has to be at the same or greater version than the source. If the target is at a greater version than the source, you will enter maintenance mode on startup to migrate the schema.

If you do not need to preserve passwords, then you could use the User Search API and the User Import API together.

Thanks for the info Dan.

Zendesk also support JWT/oAuth SSO. I guess I'll give that a try - though it seems unlikely to give a different result.

If that fails, we will rely on session timeout and disable the logout button.

@elliotdickison,

What you are looking for is some of the Auth Flows that we have outlined (pay attention to the recommended ones for a secure setup). Specifically, this one might be helpful.

The common pattern is to have a BFF (backend for frontend) to keep things secure.

We have a nice example of how to securely complete the OAuth handshake in our 5-minute guide, with a section on how to use cookies. I would start there for an overview on how to complete the OAuth handshake using express and nodeJS.
https://fusionauth.io/docs/v1/tech/5-minute-setup-guide#cookies-for-a-single-page-application

I hope this is a good starting point. Let us know if you have other questions.

Thanks,
Josh

@sohwh,

You can find our system requirements for the database listed below:

https://fusionauth.io/docs/v1/tech/installation-guide/system-requirements#database

FusionAuth should run all major Linux operating systems as documented below

https://fusionauth.io/docs/v1/tech/installation-guide/system-requirements#operating-system

I hope this helps!

Thanks,
Josh

I have added a further suggestion to the issue on the app repo.

https://github.com/FusionAuth/fusionauth-issues/issues/1250#issuecomment-859634082

@faizan

I'm not sure what you are asking for, but have found swaks to be a good tool for testing SMTP functionality from the command line.

Here's the swaks website/docs: http://www.jetmore.org/john/code/swaks/

Does that help?

As answered on https://github.com/FusionAuth/fusionauth-issues/issues/1263, this was indeed an issue with port 25.

For anybody encountering the same problem:

Try switching to another port (587, 465, or 2525) Try switching TLS to SSL and the other way around with all the different port configurations.

Took me a while to find this, probably because I mistyped 587 as 578.

In the meantime we could implemented it with the mentioned workaround.
Late thanks @robotdan !

@alessandrojcm,

Sounds good. I have logged a bug report; we should have this one squashed soon!

Thanks,
Josh

For anybody having this issue, it turned out I had written my URL wrong: http://company.fusionauth.io for example instead of https://company.fusionauth.io. The redirect to https:// caused the error.

We understand that sometimes you want to "kick the tires" to ensure that a feature will work for you, especially if you are going to pay for it.

You have two main options.

The first, which gives you the most flexibility, is to do the following:

Install the FusionAuth community edition somewhere (see the installation guide for all the options) Sign up for a developer license trial. This will require you to enter your credit card, but it will not be charged for the length of the trial (2 weeks at the time I write this). Follow the directions on the reactor page to install the license and activate the features. Cancel the trial at the end of the two weeks or before, if the features don't meet your needs. (We'd love feedback on how they didn't meet your needs, too! Please file issues to help us improve.)

The second option, which requires a lot less work but will give you less control, is to use the sandbox site. This lives at https://sandbox.fusionauth.io/ . With this option, you don't need to enter your credit card, sign up for an account or remember to cancel. This instance has a valid developer license, allowing access to all the premium features.

However, there are limitations:

Any information you enter is public and can be viewed by anyone else looking at the sandbox at the same time The sandbox environment is reset regularly to a known state, so your changes will be wiped at that time.

@spfarran

Glad you got it figured out!

Thanks,
Josh

I'm a former consultant, so the answer is, as always, "it depends".

Strengths of running in different tenants:

easier to manage (only one instance to run and upgrade) configuration, such as lambda or identity provider config, can be shared across tenants cheaper to run (again, only one instance and database to pay for)

Strengths of running in different instances:

true isolation when running you can allow developers access to the admin ui of the instance a misconfiguration in development isn't going to affect production you can have a true IaC approach, where you deploy config changes across environments one at a time

In general, it makes sense to be careful about production environments, as if any configuration changes are made in error, it can impact the customer experience.

It really depends on what works best for you.