The Rolling Back From a Problematic Upgrade guide will walk you through the necessary steps.

We also recommend testing your upgrade in a non-production environment first and closely reviewing release notes to ensure you are aware of how the upgraded version of FusionAuth will interact with your integration.

Hi @phoebe,

Thanks for using FusionAuth!

Did you get this resolved? We have a simple react application tutorial here which uses the react SDK. I'd be interested in knowing if deploying that application to Azure SWA has the same issue.

If it does, then maybe there's some additional configuration that needs to be set or a change to the React SDK that is needed. If it doesn't, maybe there's an issue with the react app you wrote.

Also, are you seeing any messages in the JavaScript console?

Hi @tobias-lippert ,

Thanks for using FusionAuth!

The current retry logic for webhooks is documented here: https://fusionauth.io/docs/v1/tech/events-webhooks/writing-a-webhook#retries

There's also a tracking issue for webhook improvements here.

If you need specific functionality not outlined there, please file an issue and then reference it on that tracking issue.

When you are month to month (MtM), it is a series of 30 day commitments, perfect for small and non production deployments that aren't needed longterm.

Contract customers typically commit for 12-36 months. For that longer commitment, FusionAuth offers discounts and a voice in product roadmap in exchange.

If, instead, customers value flexibility, they can always pay list price with no more than a 30 day obligation.

@alex-patterson It seems like you are experiencing issues with Fusionauth not hitting localhost:3000/webhooks but working correctly on webhook.site. There could be several reasons for this behavior:

Configuration: Double-check your Fusionauth configuration to ensure that the webhook URL is correctly set to "localhost:3000/webhooks" and that there are no typos or errors in the URL.
Firewall or Network Restrictions: Make sure that there are no firewall or network restrictions preventing Fusionauth from accessing localhost. Sometimes, security settings may block external services from accessing localhost.

As of July 25, 2023 we now support Unlimited Custom Domains for FusionAuth Cloud! You can read more in this post, on how to add a custom domain.

As of July 25, 2023 we now support Unlimited Custom Domains for FusionAuth Cloud! You can read more in this post, on how to add a custom domain.

As of July 25, 2023 we now support Unlimited Custom Domains for FusionAuth Cloud! You can read more in this post, on how to add a custom domain.

@andrew-1 Thanks for sharing the fix! Appreciate it!

@chris-lees Does M365 support the prompt parameter? It looks like it does.

I'd look at adding that parameter to the authorize URL that FusionAuth is generating. If you want to prompt the user every time, you can add it in the Identity Provider configuration. If you want to do it occasionally, I'd look at writing some javascript to append it to the URL in the themed pages.

Hi @nadav ,

What version of FusionAuth are you using?

What does the error log say when you turn on debugging?

Hi @pawel-prochal ,

It sounds like you want to make a request against a FusionAuth search API using a JWT issued by FusionAuth to authenticate that API request?

Unfortunately not all FusionAuth APIs use JWT authentication. User search is not one of them.

If I were going to do this, I'd build a small proxy that took a JWT and held an API key. It would examine the JWT and then make the user search API call using the API key.

Let me know if I misunderstood something.

Hi @nadav

Thanks for using FusionAuth.

What version of FusionAuth are you running?

What do you see in the error event log?

Hiya @kirill-melnikov-dev-test

Thanks for using FusionAuth!

What version of FusionAuth are you running?

Have you tried the redirect method instead of the popup method?

What do you see in the Error Log when you turn on debugging?

You can also try a straight OIDC Identity Provider.

Hi @rob-aitken ,

Thanks for using FusionAuth!

If you are seeing a 429 and are using FusionAuth cloud, you are being rate limited by our web application firewall. Our rate limits are not publicly available and may change over time, but are pretty generous. I'd check to make sure you are calling FusionAuth appropriately and/or using exponential backoff when getting a 429.

You can also file a support ticket using the account portal if that's helpful.

More information here: https://fusionauth.io/docs/v1/tech/installation-guide/cloud#captcha-and-rate-limits

@jvadaliya Hiya,

I think you need to call the hosted backend logout endpoint to delete the cookies it sets.

Thanks for using FusionAuth!

@apetrescu Sounds like a fun problem!

You are correct that entities are the best approach for this while staying entirely within FusionAuth. We don't have a lot of guidance on best practices around entities that I can share, unfortunately.

Considering these challenges, we would greatly appreciate your guidance on how best to model FusionAuth to meet our needs. We would be particularly interested in any recommendations or best practices you can provide regarding Entity management, Permissions, and Role assignments.

You might think about making an intermediate entity such as CompanyAbcAdminRole or CompanyAbcManagerRole, which would have permissions for admin or manager actions on CompanyAbc. Then you could atomically grant or remove CompanyAbcAdminRole to a user while leaving CompanyAbcManagerRole assigned.

Additionally, we anticipate that a User may have access to a potentially large number of Companies within our application, potentially reaching hundreds of thousands. We are concerned about the practicality of including all these Permissions in the JWT (JSON Web Token). Could you please advise us on an effective approach for managing and including these Permissions in the JWT? What would be the alternatives or what are the best practices on this topic?

Why would you need to do so? Is your user going to be accessing all the Companies at one time? In this case, I might offer the user the ability to choose a Company to 'enter' and create a JWT based on that action. You'd create an Company 'chooser' based on their grants to allow them to pick between the companies they know about.

If you'd like to discuss this more, consider talking to our sales engineers.

Another option is to, as you said, not use FusionAuth entities. You could instead use FusionAuth for authentication, then feed the resulting JWT into a solution like permit.io, cerbos or oso (or something home grown). You'd use that other system as the authorization solution.

Hope this helps.

When a user expires, login will fail with a 410 status code, but we do not treat this as a user deactivation. We do not yet have an event for user expiration, it really only keeps the user from logging in.

https://fusionauth.io/docs/v1/tech/events-webhooks/events/user-deactivate

There are no hard limits as to the number of users you can add.

If you notice any load spikes, you can always batch the work into multiple API calls.

This is possible using the user API

https://fusionauth.io/docs/v1/tech/apis/users

First GET the current user, identify the two-factor method you want to disable. Below you can see where the twoFactor method has one called "authenticator"

Example:

{ "user": { ... "twoFactor": { "methods": [ { "authenticator": { "algorithm": "HmacSHA1", "codeLength": 6, "timeStep": 30 }, "id": "35VW", "method": "authenticator" }, ...

Remove the object for "authenticator" and then then make a PUT call against the same User object to update.

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

Please note:

This will allow you to administratively remove a 2FA method from a specific user, and it will leave the recovery codes intact if there is at least one remaining 2FA method configured for the user. If you only have one configured method, and you remove it, the recovery codes will be cleared, and then re-generated next time you enable 2FA on the user.