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

Hi @john_doe_1,

Great question! I want to clarify a couple of things:

Are you using social login plugins that are separate from FusionAuth? Are you using an OAuth flow using our hosted pages or are you customizing your login flow?

We do offer identity providers using our OAuth flow that enable third-party login with FusionAuth. You can find more details on that here. That may be a good place to start.

Please let me know if that helps, and if not, we can brainstorm some more solutions together.

@alan-wood,

In reviewing with the team, looks like there is another path forward regarding original bullet #3

Add an Idp (you could use google for instance) Add a consent from settings > consents Add a form field referencing this consent Make an advanced registration form Add previously created form field/consent to this form Create a new theme (or extend your existing non-default/shipped theme) Modify the theme to remove the display of the username and password in FreeMarker Navigate to customizations > themes > all affected templates (in my case, this was the OAuth register template)

Here is the simple Freemarker that I used to modify (disclaiming now that you may want to rework this code a bit -- example only)

[#-- Begin Self Service Custom Registration Form Steps --] [#if fields?has_content] <fieldset> [#list fields as field] [#if field.key == "user.username"] [#elseif field.key == "user.password"] [#else] [@helpers.customField field field.key field?is_first?then(true, false) field.key /] [#if field.confirm] [@helpers.customField field "confirm.${field.key}" false "[confirm]${field.key}" /] [/#if] [/#if] [/#list] </fieldset> <div class="form-row"> [#if step == totalSteps] [@helpers.button icon="key" text=theme.message('register')/] [#else] [@helpers.button icon="arrow-right" text="Next"/] [/#if] </div> [#-- End Custom Self Service Registration Form Steps --] Now when I see my register page, I get view like this. The Idp that you select will use the hidden username/email and password fields.

You are going to want to also customize the label for the consent. More information can be found below.
https://fusionauth.io/docs/v1/tech/guides/advanced-registration-forms/#consents

804d24ad-6884-411f-812e-85cb26406b7b-image.png
⬇ ⬇ ⬇
1b22fb15-8544-4b19-a267-54aeea3236ad-image.png

Does that require completely replacing the UX flow you have with my own hosted one?

Yes, I believe that you would have to do this to add your own pages.

Thanks so much for writing this up @sswami !

Hi @alex,

Yes, you are correct -- there is not a configuration for setting the host within FusionAuth. There are workarounds, but it sounds like you were able to find the most optimal solution using cloud network configuration settings.

Thanks,
Josh

Hi @rvogelgsang,

Sorry to hear you are having trouble! If you had a bit more details that might be helpful.

For instance:

What environment you are running FusionAuth in and what client package you are using? Sounds like maybe our typescript client? Where are you setting the custom ID and what errors are you seeing? An example code snippet if possible Additional context about what you are trying to achieve in your code etc

If this is ultimately a bug, we can file a bug report as well. Thanks and let us know!

Thanks,
Josh

No, this is not currently possible. Here's an open issue, please upvote it if this is a crucial feature: https://github.com/FusionAuth/fusionauth-issues/issues/1082

One alternative to repeating content would be to use some kind of generation system outside of FusionAuth (freemarker, handlebars) to generate text files. Then you'd then upload as the email templates via the API.

Use docker?

This error is related to FusionAuth not being able to communicate to nodes over TLS in a multinode environment.

Two things you will want to check-

If you are using self-signed certs (TLS)

You will need to add any self-signed certificates to your Java Truststore.

If you are using a signed cert from a certificate authority

Make sure you have properly integrated that cert into your TLS

Lastly, If you are on a secure private backplane, you can simply communicate over non-TLS (HTTP).

Once FusionAuth can establish a connection, then the caching issues should remedy themselves. In a multi-node environment, the first node is kickstarted with its own cache and then attempts to inform all other nodes to refresh their cache. If this "master node" cannot communicate (in this case due to not have the right security cert), then you will see errors such as above.

Thanks,
Josh

Hiya,

We have 4 different options for that.

https://fusionauth.io/docs/v1/tech/guides/api-authorization/

Client credentials is the most straightforward, but requires a paid license. The other options are outlined in detail in that doc.