Basic Questions regarding FusionAuth
-
Hello everyone,
I have some basic questions if anyone has already come across such scenarios, please share your experience or strategy regarding how you solved this problem.
-
In my application solution, I have a test and production system. Is there a possibility to define a test and production environment separately(with two different databases) within the FusionAuth server to do the authentication and authorization or I have to purchase a separate solution of Fusion Auth Server for each environment?
-
Fusion Auth cloud, it hosts the fusion auth server right?
Does it also include a Database by default to store the data of users? or we can attach the custom Database to it?
(On the price description, there is a feature "3 nightly database backups." From there, I am perceiving that it has a built-in database to store user information, is that so? )
-
In the order summary of the Basic hosting plan of Fusion Auth Cloud, it is written that "Complete Data loss could occur if the server or disk crashes. This is not recommended for production deployment. "
Does that mean that there will be no recovery in that case? User Data will also be lost?
-
Migration and export:
1 In the future because of some unforeseen circumstances, is there any possibility available in fusion auth to transfer the existing fusion auth Database data to a new fusion auth Database?
2 Can you please also highlight, is there any possibility to export the user/groups/tenants/application data from the FusionAuth cloud later at any point in time? -
Lastly, Can you please highlight, if I decide to take Developers plan for FusionAuth edition and Business plan for
fusionAuth Cloud, what are the possibilities to upgrade and downgrade from these plans in the future?
Thank you so much in advance.
-
-
In my application solution, I have a test and production system. Is there a possibility to define a test and production environment separately(with two different databases) within the FusionAuth server to do the authentication and authorization or I have to purchase a separate solution of Fusion Auth Server for each environment?
We recommend running two separate fusionauth servers. Test can of course be a smaller system than production. You can also run your test environment on a digital ocean droplet or something similar. Then you'd be responsible for upgrading, security, etc. FusionAuth has a community edition which is free to download and can be used for any number of users and you could install that anywhere you want.
Fusion Auth cloud, it hosts the fusion auth server right?
FusionAuth cloud does indeed provide a database. You cannot use a different database for security reasons. You are, of course, free to run FusionAuth on your own servers.
In the order summary of the Basic hosting plan of Fusion Auth Cloud...Does that mean that there will be no recovery in that case? User Data will also be lost?
We don't recommend using the Basic plan for production. Instead, it's recommended that you use it for testing or dev environments where data loss isn't an issue. Basically at that hosting level the database and FusionAuth are running on the same server and if there are any issues with it, the data in the database could be lost.
In the future because of some unforeseen circumstances, is there any possibility available in fusion auth to transfer the existing fusion auth Database data to a new fusion auth Database?
I'm not sure what you mean here. Do you mean moving from one FusionAuth cloud plan to another? In that case, FusionAuth would take care of the transfer. Do you mean moving from FusionAuth cloud to self hosted? In that case, you'd request a database export and stand it up yourself.
Maybe I misunderstand the question you are asking.
Can you please also highlight, is there any possibility to export the user/groups/tenants/application data from the FusionAuth cloud later at any point in time?
You have full access to the APIs and those can be used to export user/groups/tenants/application data. You'd have to write the export scripts (or ask the community for them) but the APIs expose everything. We can also provide a database dump on request (within reasonable limits).
Lastly, Can you please highlight, if I decide to take Developers plan for FusionAuth edition and Business plan for fusionAuth Cloud, what are the possibilities to upgrade and downgrade from these plans in the future?
You can upgrade and downgrade by opening a support ticket and pricing is pro-rated.
Hope this helps.
-
Thank you so much for your reply.
Can you please also highlight,-
Is it possible to keep different(custom) Databases for each tenant?
(so far I couldn't find such an option in the fusionAuth dashboard.) -
From the interface point of view, is it possible to use existing registration and login workflow process implemented in my application and directly call the API to create register users?
Instead of using the theme setting or importing the code within the theme setting on fusionAuth server?
(In my registration workflow, I have multiple pages which step by step take input of user information necessary for registration) -
Also is it possible to define and store more custom fields during user registration and login process? Fields like privacy consent, agree to terms and conditions, etc? (other than username/email and password)
(I don't see any option in the dashboard to add more fields in the schema.)
Best regards,
Humaira -
-
@humaira-tum11 said in Basic Questions regarding FusionAuth:
Is it possible to keep different(custom) Databases for each tenant?
Nope. If you want different databases, you should run different fusionauth instances.
From the interface point of view, is it possible to use existing registration and login workflow process implemented in my application and directly call the API to create register users?
Absolutely. You'll just call the APIs directly using the client library of your choice. If we don't support your preferred language, please file a github issue. Here's a brief tutorial on this process.
Also is it possible to define and store more custom fields during user registration and login process?
You have two options for this. For arbitrary key value data, you can store it in the
user.data
field (or, if it specific to a user registering for an application,user.registration.data
). If you are specifically to track consents, you can use the Consents API. -
Hello,
thank you so much for your reply that was very helpful.
Unfortunately I have some more questions it would be super helpful if you can answer them too.Q - I can see we can create applications and add tenants to them, which can't be edited/changed later. Is it possible to Add multiple tenants to one application? And maybe change the tenant later.
Q - Also, on the documentation, it can be seen that in order to support multi-tenant or offer services to more than one client.
In this scenario, it is suggested to maintain separate Users, Applications, and Groups for each of your clients.1- Which means that every application would be representing one client, then why do we need tenants,, why do we even have tenants there?
2- what is the purpose of multiple application and multiple tenants?
Best regards,
Humaria -
I can see we can create applications and add tenants to them, which can't be edited/changed later. Is it possible to Add multiple tenants to one application? And maybe change the tenant later.
Nope, applications are contained within tenants. Here's a blog post talking about multi tenant in FusionAuth.
Also, on the documentation, it can be seen that in order to support multi-tenant or offer services to more than one client.
In this scenario, it is suggested to maintain separate Users, Applications, and Groups for each of your clients.Yes, you can think of a tenant as an entirely separate installation of FusionAuth. So you'd have to create users, applications and groups for each tenant. Another way of structuring this would be to have an application for each client. Which you choose depends on how much separation you need.
what is the purpose of multiple application and multiple tenants?
The main purpose of using tenants in the higher level of separation. If you want each client to have their own FusionAuth theme, API keys, and a separate user space, then you want multi tenant. If you don't care about the themes, tenant scoped API keys, or that someone with the same email address wil have the same password for the application of client A and client B (because both use the same FusionAuth and live in the same tenant, the user will have the same password for each application), then separate FusionAuth applications in the same tenant will work.