Good question. I believe this is due to how we implemented our PATCH calls. If you are making a straight API call, you can change the Content-Type header to application/merge-patch+json which will instead overwrite the existing array with whatever you have provided. That's the most straightforward way to replace array values. There are other methods detailed in the doc below but those involve removing values one by one instead of just overwriting them. The downside here is that I don't believe Client Libraries usually support the merge-patch header.

• https://fusionauth.io/docs/apis/#the-patch-http-method

The UserData of our users contains an array which is creating a problem for us using PATCH. When PATCH is used to refresh the user it always results in an array append. It appears that one option is to perform a GET request, modify the array, and then execute a PUT request. That's multiple steps, and thus more opportunities for something to go wrong. Can the array values be replaced with a PATCH rather than adding to the array?

If you believe that you have discovered a bug or issue with FusionAuth, please log an issue below.

• https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

To note, you will likely want to be listening to the registration.update webhook for changes to the registration object prompted by additional fields the user needs to have completed based on what is a required field for self service registration.

In the case of a user entering all these fields "manually" (as part of a registration form) we will create the user and the registration at the same time (thus transmitting all information, including all required registration fields, as part of the user.create and registration.create events).

However, in the case of a social login, the user and registration will be created after the IdP provider returns information via the user.create and registration.create events. Additional registration will be asked of the user as part of the complete registration process (if there are additional required fields) and that additional information will be transmitted as part of the registration.update event.

• https://fusionauth.io/docs/extend/events-and-webhooks/events/user-registration-update

My registration form includes custom fields. The values are correctly sent to our backend with the user-create-complete event. Unfortunately, this does not apply to users who register with social login. At this point, the event is dispatched without the supplementary custom content, as it occurs immediately after the social login and before the user is prompted to provide additional registration details. Consequently, I anticipated a user.update.complete event to occur shortly after the 'empty' user.create.complete event, but it did not happen. Please provide guidance on how to troubleshoot this issue.

The transient policy is not something FusionAuth will support for the SAML NameID policy. From the SAML standards doc, a transient NameID is supposed to be a temporary value which is not a good basis to build a link between two identity systems on. That is the main reason FusionAuth does not support this policy as it would likely lead to issues later down the line with the Identity Provider. Apologies for the inconvenience but having the User ID/UUID shift or change would cause problems as FA relies on a consistent User ID/UUID(NameID) to make a SAML link work.

• http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Our intention is to utilize FusionAuth as a SAML Identity Provider (IdP) for Omni.

Our efforts to accomplish this were unsuccessful due to FusionAuth's lack of support for the "transient" NameIDPolicy (urn:oasis:names:tc:SAML:2.0:nameid-format:transient). This is detailed in the documentation at: https://fusionauth.io/docs/lifecycle/authenticate-users/saml#limitations.

Omni is working on supporting one of the other NameIDPolicies, but it will take them some time. Their pull request was integrated: https://github.com/siderolabs/omni/pull/1292. However, they still need to implement additional modifications concerning their Go library that implements SAML and Omni's infrastructure.

Is there a way to get FusionAuth to support the "transient" NameIDPolicy on your end? This would enable Omni to work with FusionAuth, as well as other Service Provider's (SP) that do not support FusionAuth's list of NameIDPolicy values.

Currently, there is not a way to turn it off. Our air gapped license is still going to try to make that call out to us, but that won't cause any issues. The difference being that a normal license would have issues if it could not "phone home" back to us whereas the air gapped license won't have issues but it will still try to make those calls.

We operate FusionAuth on an airgapped network and have the correct license. Every 23 minutes or so, it still attempts to connect to reactor.fusion.io, filling the Event Log with error messages indicating that it cannot resolve the IP address. Other than making it difficult to identify genuine error messages, I don't believe it causes any damage. Can this be turned off somehow? This is what the error looks like:

Unable to retrieve the IP location database last update instant and digest. Status code [-1], last modified date [null], and digest hearder [null]

Exception:

java.net.UnknownHostException: reactor.fusionauth.io

<big java stacktrace>

If you want to change the font on the hosted login page and the login experience users are offered through FusionAuth, then this can be changed via our Themes. Very likely you will want to update the CSS associated with the theme you are using for the FusionAuth Application/Tenant. Changes to the theme can be completed through this API: https://fusionauth.io/docs/apis/themes/advanced-themes.

Alternatively, you can use the Admin UI to make changes to your CSS as well.

We would like to change the fonts on our TOH user interface from the old set (Montserrat/playfair) to something different (Mulish). Is this something that you do on your side or is it something we can do?