@joshua said in Fusion auth is creating 2 sessions when a single user logs in? Is this correct?:

Depending on how you are using FusionAuth, this is normal. One of the sessions is going to be the SSO session. And the other is going to be an Application level refresh token. There could be possibly other refresh tokens present as well, depending on your use case and integration.

Thank you for your response. However I have another question, backend is calling logout api of fusion auth by passing refresh token, now it only deletes 1 session. The other session remains and on client side user is logged in on fusion auth. Now to logout from client side I am redirecting user to fusion auth logout url to delete that remaining session. Is this intentional, if yes, then is there some other alternative?

@sandesh Thanks for sharing her on the forum. Hope you are able to accomplish your end goal with the APIs.

@dan I would love for this to be included in the themes documentation since it's something that every theme developer needs to figure out, and of course the default theme's assets (favicon etc.) are hosted locally and served by the FusionAuth server itself - so the answer that this can't be done for your own theme assets is non-obvious!

You have a few options, none of them great.

You could look at using universal links and android app links to make sure the redirect URL for both mobile and web apps has the same format. You could, on the Change Password Template, put in a message making it clear to users that if they started the change password flow on a mobile device, they should finish it on a mobile device (and same with web apps). You could, on the Change Password Template, write javascript to examine the user-agent and the redirect URL. If they are incompatible, you could redirect the user to a device-compatible change password URL (basically by rebuilding the change password link they clicked on to start the flow and then doing a window.location=... call).

We actually just launched a feature using the Vend API to do impersonation. Seems to be work well so far.

Basically just pass in a UserId with the ApplicationId you wanted to impersonate (for us), call the GetUser API, and then build a claims map from User (roles, entity grants, etc) into the right structure and pass that JWT back to the calling app to leverage.

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.