Hi @reece-temple,

Can you confirm you created the My-Sql database when you created your Digital Ocean droplet?

If you have any screenshots of error messages that you are seeing either on your browser or your command line, that would help as well.

Thank you!

Akira

Thanks @dtokarz1

I agree; this would be a nice feature to implement for edge cases.

Thanks,
Josh

Thanks for replying. I am following up to let you know what happened. I clean installed 1.29 and the mysql connector J file was there but I received that error. I copied the file from a known working install of fusionauth, it prompted me to overwrite the current file which I accepted but I still received that error. After troubleshooting some more I gave up and did a clean uninstall/reinstall.

This time the mysql connector J file was not there. I copied the same file from the known working install of fusionauth and everything worked. I can't explain why but a full uninstall/reinstall and copying the mysql file fixed my issue. Maybe this can help someone else!

It may be that you have set up your system to remove unverified users after a certain period of time.

To modify this setting, navigate to Tenants > Edit Your Tenant > Email then to the Email verification settings section.

In this section, you can change your email verification requirements and durations.

Generally speaking, the provisioning depends greatly on the infrastructure being requested as well as the current demands placed on the underlying cloud infrastructure provider.

For smaller deployments, you can expect a 5 to 10 minute timeline. For a setup more aligned with a high-volume system with large CPU and database capacities, you can expect a provisioning time of 20 to 45 minutes.

@aaron

Too add to what Akira mentioned, please keep in mind that advanced registration forms are a paid feature (developer plan or higher) within FusionAuth. Within this feature set, you can use regex commands and add your own custom validation as shown below.

Additionally, under tenants > password there are a number of custom password rules that you can set as well.

In addition to the tenant, there are also some password rules that you can configure on the application level under applications > registration > self-service registration > enabled > type: basic . Here is where you will find a confirm password toggle as well.

Finally, the above applies to a POST event. Meaning the form has to be submitted before feedback is displayed to the user indicating that they failed validation.

There are some Github issues that we are tracking for more realtime validation like events as well. If you have a unique use case - feel free to log an issue as well.

https://github.com/FusionAuth/fusionauth-issues/issues/1223

Thanks
Josh

If they are on community there is no license. So from community to any paid edition you’d have to enter the license key.

Other than that, no change to the config is required or expected.

If you are changing from a paid edition to community edition, log in to your account at https://account.fusionauth.io and modify the edition. This will render the existing license key inactive.

And here's the blog post: https://fusionauth.io/blog/2021/07/23/announcing-fusionauth-1-29/

Apart from email verification, where gating is supported, all of these checks are business logic and need to be performed in your application.

The current solution is to put the value into the JWT as a custom claim using this lambda: https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate/

And then have your application check this when it is verifying claims (as it should do).

There are some open issues on this:

@rvogelgsang to follow on with what @akira wrote, you can also just set the password to a random unknown string too.

However, a new install will always have the same schema version as the product version. So a clean install of 1.29.0 will always show a schema version of 1.29.0.

This does not necessary mean there is a migration for 1.29.0. The correct way to know which versions have a schema migration is to extract the contents of the database-schema zip. It will also be noted on the release notes.

Ensure you are not using a reply address from @fusionauth.io; if you are this will fail our DMARC policy.

You don’t necessarily want to remove this reply address, but it should not be using our email domain. Instead it should be an address that belongs to your organization, such as no-reply@example.com. (Or, even better: customersupport@example.com--I hate when I get an email I can't reply to, myself.)

Each email template also has the option to override that default value with a different value. So you may also want to audit each email template to ensure if it is using a different From address, it is also owned by your domain.

If you are using email verification, you can check this user state within your own app. (So, don't allow the attacker to access anything until their email address has been verified.)

In version 1.27.0 you can configure a gated login flow when the user is not verified (this is a 'reactor' feature requiring a paid license). This will enforce email verification before we even redirect to your app. You can then also configure FusionAuth to delete users after N number of days if the user has not verified their email address. This can assist with build up of accounts that are not actually in use.

@sandrat,

Sorry to hear that you are having difficulties.

You guys do the download thing to trial, be a piece of cake but the install isnt nearly as smooth as you think.

Can you elaborate on any difficulties that you had attempting to install FusionAuth locally?

Simple a couple of SPs against your SAML IDP and I will know if we are in the play.

If you could elaborate on what you looking for I may be able to assist further.

Below is our existing documentation:

SAML as IdP:
https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/#overview

SAML as Service Provider:
https://fusionauth.io/docs/v1/tech/samlv2/

Current Limitations:
https://fusionauth.io/docs/v1/tech/reference/limitations/#saml

Thanks,
Josh

That is correct. Each time a user is updated, a user.update event is fired, or a user.registration.update (if a registration is updated).

@justinfox,

There are a few ways in which you can architect this to ensure the user/entity is authenticated and authorized (reader here) depending on the language and architecture used. The tutorials and guides cover a few different approaches.

https://fusionauth.io/learn/expert-advice/authentication/login-authentication-workflows/ offers a high-level overview as well.

Lastly, if you decide to use OAuth, you could consult our modern guide to OAuth for more information.

https://fusionauth.io/learn/expert-advice/oauth/modern-guide-to-oauth/

Thanks,
Josh

@justinfox,

Awesome, glad that you got it working!

Thanks,
Josh

@daniel,

Glad you are trying us out! I will do my best to address your questions.

if the API is an Entity, and mobile app is an application, how roles will be designated to users for the APIs? How do we access them there? Is it done via same approach as in Auth0?

Are you saying that you are looking to have the same roles (they are called permissions the entity types) assigned to an entity and a user? I may need a little more context to better understand. Maybe you could outline how you are expecting this to work in practice.

Side note, we have documentation on this to be found here (you may have already reviewed it).

https://site-local.fusionauth.io/docs/v1/tech/core-concepts/entity-management/
https://site-local.fusionauth.io/docs/v1/tech/apis/entity-management/#undefined

Also there is a question about using Roles by tenants - as we plan to create those roles, while Tenants will be assigning them to their users, is that actually possible?

Roles are scoped to an application per documentation. I might need some additional clarification/context to better address.

https://site-local.fusionauth.io/docs/v1/tech/core-concepts/roles/#overview

Let us know. Happy to help as able!

Thanks,
Josh

@chasermina21

I have removed your replies, as they seemed a bit out of context.

Please see our community guidelines.

https://fusionauth.io/community/forum/topic/1000/code-of-conduct

Thanks,
Josh