You could look at the password last update timestamp (passwordLastUpdateInstant) which is an attribute on the user.

See if there's been any change since the initial email send (or since the issue). If there had been no change, you should be able to resend the email.

Sure, you can migrate the database. I'd make sure that the versions of FusionAuth are the same.

Here's another similar topic: https://fusionauth.io/community/forum/topic/1091/migrating-users-from-one-server-to-another-how-to-do-it

@richb201,

I cannot speak to how RDS within AWS configures/performs their DB backups. A typical workflow for customers is to use PG dump. Once the DB is dumped, you can run a PG Restore (or equivalent MySQL command if needed). To verify data integrity, you can check the total number of records before and after the database dump. RDS AWS backups may be just as seamless, but I cannot speak to them as I have not used them.

The only other thing would be to be mindful of is encrypting your data in transit. There are a number of tutorials online that incorporate or give consideration to encryption and security as part of a DB backup / restore operation (AWS may even have a guide).

I am 99 percent confident that FusionAuth persists most of your data in the database (with the exception of possibly Kickstart files). So you would stand up your database (back up or otherwise) and point FusionAuth to that database. From there FusionAuth should work. You will likely need to reindex your data (from the Admin UI) to reestablish your User and Entity search indexes.

If you are concerned, you run a trial operation in the cloud. Standup a docker image, connect to an RDS from AWS. Back it up. Stand up the backup. Point FusionAuth to the new database. Confirm that everything is as it should be.

I hope that this helps!

Josh

@twilkinson -

Your welcome 🎉 Super! Glad you got it working!

Josh

We want to be able to send different templates depending on the user and that is the only way I saw without creating different Applications or Tenants

In this case, I would explore not using FusionAuth to send the emails. If you want more granularity than application, you can build your own.

send the email yourself (you could manage the templates in FusionAuth if you want, and pull back the templates and build the email html/text) using a service like sendgrid, etc. Build a link to take the user to a custom page you build with their email address (remember to make sure to disallow spoofing) Use this API to change the password ("Changes a User’s password using an email address or username." ) https://fusionauth.io/docs/v1/tech/apis/users/#change-a-users-password

Of course, this means you have to handle password resets securely, but it gives you the flexibility you want.

Another option is to build the logic into your templates. You can pass in a state variable to the 'forgot password' API call ( https://fusionauth.io/docs/v1/tech/apis/users/#start-forgot-password-workflow ) and that state is available in the template. This state can be any json object, so you could pass the username, group the user is in, their favorite color, or anything else. Then, you can retrieve that state in the template and conditionally render items.

Initially we thought the send-email API would be enough. But we stumble on the following problem:

It is necessary to have a setPasswordID and it seems that there is no way of setting up this id.

I didn't see this setPasswordID variable referenced anywhere in the docs. Can you please give a link to where you saw it? The changePasswordId is used both to set the password the first time and to change it in the future.

HTH.

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.