Options:

Hints will direct a user to a specific IDP (but not forcibly - the user can still change the URL). https://fusionauth.io/docs/v1/tech/identity-providers/#hints You could look at issued token at the application level and verify the claim of authenticationType and ensure that it’s GOOGLE when the claim is user.data: admin and if not kick the user back to login with a helpful message on the way out. However, any refresh grants won't retain the initial login type: https://github.com/FusionAuth/fusionauth-issues/issues/1483 Another option might be to key off of user.login.success webhook and fail the login (send a non-200) if the user is an admin and the authenticationType is not GOOGLE: https://fusionauth.io/docs/v1/tech/events-webhooks/events/user-login-success

Webhooks will send the data documented below. What is sent will vary according to the webhook event

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

Cookies are usually stored in a browser, but you can send custom data to a webhook by including an eventInfo.data object:

{ //.. "eventInfo": { "data": { "myCustomData": "FooBar" } }, //... }

So you could read from a cookie and set a form value, for example on a login event.

More details here: https://github.com/FusionAuth/fusionauth-issues/issues/2263

We do not have a current mechanism to check how big the headers will be from FusionAuth. Out of the box, FusionAuth will not set more than 1024K in headers.

Therefore, if you are seeing a 502, this suggests a proxy configuration issue or another integration issue with how you have set up your infrastructure. You could try tuning your values and proxy settings (as you have suggested).

We also have a community-contributed proxy configurations that you might find helpful: https://github.com/FusionAuth/fusionauth-contrib/tree/master/Reverse Proxy Configurations

Yup, this is expected.

The data returned by the IdP may have changed, so FusionAuth will update existing links on each login and sends the event each time in case the data has changed.

@mark-robustelli

right on. I will use that next time.

@sandesh Thanks for using FusionAuth!

I wanted to know if we can pass a custom data with membership field with JWT token.

You should be able to grab it out of user.memberships in the JWT populate lambda. I just tested this out:

console.log('membs: '+JSON.stringify(user.memberships));

and I see the data field.

If yes, can we configure a field from front end like we can do for a User registration page where the field is passed as user.data.fieldName.

This is not possible now. The only objects on which you can set custom data using the registration form are user and registration.

Since you can't add a membership at registration time, I'd suggest using a webhook on registration completion to populate the membership.data field.

@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.