@sandesh Great, glad you figured it out!

@sandesh I'd suggest using a UUID generator. Most programming languages have one, or you can use FusionAuth's: https://fusionauth.io/dev-tools/uuid-generator

Those events without the complete suffix are sent before we commit the database transaction and the ones with complete are sent after we commit the transaction.

This means that the actual entities (user and user registration) don't actually exist when the first non-complete events are emitted.

Take a look at our Calling FusionAuth APIs In Webhooks guide for more details.

Hi @david-pautler,

Sorry for the confusion! The users in account.fusionauth.io and your cloud instance are a disjoint set and do not have to be related at all. There's no synchronization between these two sets of users, and they actually run on different virtual hardware and do not share a database.

So assigning roles to users in account.fusionauth.io won't have any effect on users in <your fusionauth instance>.

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!