@aartiyadavpersonal

Please be mindful of our posting guidelines, as I do believe this question would be better suited for a computer science special interest forum - there is much variability to consider when making career choices. This conversation is a worthy conversation to have, but may not be related to FusionAuth directly.

Thanks,
Josh

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

BE CLEAR AND STAY ON TOPIC
Communicating with strangers on the Internet can be awkward. It's hard to convey or read tone, and sarcasm is frequently misunderstood. Try to use clear language, and think about how it will be received by the other person.

This applies to sharing links, as well. Any links shared in the Community Forum should be shared with the intent of providing relevant and appropriate information. Links should not be posted to simply drive traffic or attention to a site. Links should always be accompanied by a full explanation of the content and purpose of the link. Posting links, especially unsolicited ones, without relevant and valuable context can come across as advertising or serving even more malicious purposes.

Additionally, the FusionAuth Community Forum is for collaboration, sharing ideas, and helping each other get stuff done. Off-topic comments are a distraction (sometimes welcome, but usually not) from getting work done and being productive. Staying on topic helps produce positive and productive discussions.

SHARE MINDFULLY
When asking others to give you feedback or collaborate on a project, only share valuable and relevant resources to provide context. Don't post links that don't add value to the Topic, and don't post unsolicited links to your own projects or sites on other user's threads.

Additionally, don't share sensitive information. This includes your own email address. We don't allow the sharing of such information in this Community Forum, as it can create security and privacy risks for the poster, as well as other users. If you'd like to invite other Forum members to collaborate on a project or work with you, share a link to the repository in which the project you are working on exists. By sharing the link to your project repo - with some information on what your project is and what kind of help or feedback you're looking for - you can invite others to collaborate with you via issues or pull requests without having to share your private information. You can also add others as outside collaborators on your project repo to give them special permissions to help you develop your project.

No. But the user.bulk.create would. See https://fusionauth.io/docs/v1/tech/events-webhooks/events/#user-bulk-create for more details.

@dtokarz1

Interesting fix. I will have to consider why your solution worked. In the end, glad that you were able to get it working!

Thanks,
Josh

Thanks @dtokarz1

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

Thanks,
Josh

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.

ba3d6675-f745-4ace-9ce5-2c633c2a5f52-image.png

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.

@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.

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,

Awesome, glad that you got it working!

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

@dan Great. Thanks for info.

Hi @mdobron17,

Thanks for writing in! For what it's worth, the way you are approaching it now is a great way to do it. When you log in to GitHub with an OIDC IdP, we store away the refresh token, and don't auto-refresh the GH JWT. That is up to you, as the developer.

It's worth mentioning that even if we built functionality to store the Refresh Token and the Access Token, the JWT Access Token eventually expires and needs to be refreshed, which would put the burden back on you to refresh the token.

You're free to open a GH issue to suggest we expand how we handle tokens from 3rd party IdPs, if you'd like. You can do so here.

If you'd like a little more of a deep dive into configuring OIDC with GitHub, we have a post on that here.

Hopefully this helps, please let me know if you have any more questions!

@craynor

You may want to review our documentation

https://fusionauth.io/docs/v1/tech/connectors/

In contrast to using an OIDC Identity Provider, with a Connector the user doesn’t choose their identity provider; the administrator does. In addition, if the data source contains additional user profile information, a Connector allows you to map that into your user object. Finally, the data provider doesn’t have to implement the OIDC specification.

Let us know if you have additional questions!

Thanks,
Josh