Posts made by wesley

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?

Yes with a Basic Cloud you get one custom domain and no backups, you would just need to update your DNS records to include our CNAMEs for this custom domain. You would submit your custom domain via the Hosting tab of the account.fusionauth.io under the Action Drop down. Then you will be shown the CNAME record for that domain and you will have to update your DNS records to include this CNAME. You can see an example of this at the doc below.

https://fusionauth.io/docs/get-started/run-in-the-cloud/cloud#custom-domains

You would not be able to use your own SSL certificates. We would handle all those in FusionAuth Cloud. We create the certificates on our end and you just need to create DNS records to validate the domain with the CNAME records.

Before upgrading my package, I want to verify that the Basic Cloud hosting allows for one custom domain. Is that accurate? Furthermore, is there support for custom SSL certificates? How does that function?

Thanks for the question. Updating your instance wouldn't change your situation. Currently, the only options are what you found outlined in the documentation you mentioned.

• https://fusionauth.io/docs/get-started/run-in-the-cloud/cloud#captcha-and-rate-limits

As we build out our Cloud Offerings there may be other options, but this is what is currently available. Oftentimes, we find that people will use a local copy of FusionAuth to complete their automated testing if they cannot locate an IP address that meets our allowlisting requirements.

We are developing our automatic frontend tests for our application that integrates FusionAuth. Currently, we are encountering a captcha that is preventing our tests from running on developers' computers. Based on FusionAuth documentation, we can obtain a whitelist for our static IP; however, some developers work remotely, and we plan to integrate tests into our CI/CD pipeline in the future.

We are searching for a solution; at the moment, the whitelist for static IPs is the only available option. Are there alternative solutions? Our instance is on the older infrastructure, we could update it and set a custom domain but in the current setup it will be a subdomain which would not enable the use of the same cookies because it will not be the same origin.

There are a few ways you can get what you need. You can either make these changes via the API and then they will be updated in the UI.

• https://fusionauth.io/docs/get-started/core-concepts/users#user-data

• https://fusionauth.io/docs/apis/users#update-a-user

Or you can do this using custom admin forms:

• https://fusionauth.io/docs/lifecycle/manage-users/admin-forms

I would like to be able to change a field in a user's user.data, but the "Manage" user screen does not show me user.data. How can I do this?

The license ID is just the license key itself. You can grab your license here https://account.fusionauth.io/account/plan/. Each license will have a prod key and non-prod key, for testing you just need to grab the non-prod key and use that for your license ID in Kickstart.

https://fusionauth.io/docs/get-started/download-and-install/development/kickstart#set-your-license-id

I'm having trouble finding my non-prod Reactor license ID. I'm able to download the license but can't find the associated ID. License ID is a required input for the API so I'm unable to run FusionAuth locally in a container for testing without it and I appear to be unable to use my non-prod license via Kickstart in a container without the License ID as well. Where do I find it?

If you are using the React SDK (which uses Hosted Backend: https://fusionauth.io/docs/apis/hosted-backend, then there are a couple options but they will all require some integration work from your end. The SDKs and Hosted Backend are designed to be easy to use and implement but they are not flexible as you can see with the cookies. Also I'm not sure if this was a consideration in the decision that running FusionAuth locally is not an option but just in case it was: You can use your FusionAuth non-production licenses wherever you want, we do not charge more "per deployment". So you can activate your non-prod license on a locally hosted FusionAuth instance in addition to your FusionAuth on Azure App Service, you can run your non-prod license on as many instances as you want.

1. Develop your application while hosting it on Azure App service so FusionAuth and the app are on the same domain

2. Setup a proxy for either your application or FusionAuth so they can be on the same domain

• Documentation for setting up a proxy for FusionAuth: https://fusionauth.io/docs/operate/deploy/proxy-setup

3. Create your own Hosted Backend, example here: https://github.com/FusionAuth/fusionauth-javascript-sdk-express/tree/main

4. Similar to #3, instead of setting up a Hosted Backend use the OAuth2 endpoints directly. In this scenario you will also be responsible for doing the OAuth code exchange for a token then setting the token cookies on the browser as well as session management with these tokens.

https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/endpoints

https://fusionauth.io/docs/operate/secure/token-storage

We are working on creating a React application on our local machine (localhost) and need to authenticate users through our FusionAuth instance, which is hosted in an Azure App Service. We have faced cross-origin and cookie-related problems when the app operates on localhost while FusionAuth is located on a different domain (specifically, our Azure App Service endpoint). The FusionAuth documentation indicates that these problems are anticipated because of browser security limitations concerning cross-site cookies. It also suggests that a good way to address this is to run the application and FusionAuth on localhost during development. However, in our case, FusionAuth needs to be hosted on Azure App Service so running it locally is not a feasible option.