@mark-robustelli , thanks the issue though was my web app was sending the nameid format as persistent after removing it the issue was resolved.

what about the password start event? will webhook receive a event for a user who does not exist in fusion auth?

This will be good feature especially if slow migration is used for migrating users

Coming back to report my experience for future reference.

I tested going from version 1.18.7 up to 1.50.1 and it was actually possible to go straight from one to the other, i.e. install 1.50.1 and let FA automatically upgrade the database.

If you are using custom themes, many new templates have been introduced and will be missing. A small issue that will come up in this case (specifically after version 1.37) is that the index page will be broken. This is because a new index template has been introduced and will now be missing. You can circumvent this by either appending "?bypassTheme=true" to the URL, or going directly to the login page "/admin". You can then login and fix any theme issues through the dashboard editor.

Another issue I faced was that for some reason (didn't look into it), any changes I made to my custom themes would silently be discarded. I had to duplicate the default theme and start from scratch. Given the many differences and depending on your use case, this may be a good idea anyway.

@mark-robustelli thanks for the documentation link. I used a version of the "Logout Requirements" example to redirect to an endpoint that removes any fusionauth.known-device.* cookies before redirecting back to the application.

Do you think the Hosted Backend should remove fusionauth.known-device.* cookies when it removes the other tokens, at least in the case where fusionauth.remember-device is false?

Otherwise, it seems certain we will hit the HTTP 431 error whenever an application is accessed on a shared device with ~100 users. Or is the Hosted Backend not something FusionAuth envisions people using in production?

@kasir-barati When you say "I dunno if we can use them to change what Get /me endpoint returns", you might want to check out the UserInfo Populate Lamba.

It seems like FusionAuth's email server is acting up, even though SWAKS shows no problems with your own email server. You might want to try using other services like SMTPget or Amazon SES for sending emails through FusionAuth. Make sure your FusionAuth SMTP settings are set up correctly, and if the issue continues, contact FusionAuth support for help fixing it quickly.

Hey @dan,

I guess I need something similar for user.data.username. I need to define a rule on this custom user data to be unique in my app or tenant. As of now I really do not care about tenant or app since I only have one tenant and one app in my FusionAuth.

So I've asked this Q&A and I need to enforce uniqueness for this data. But dunno how to do it. Any suggestion?

I tried to specify both username and email and I got this error:

{ statusCode: 400, exception: { fieldErrors: { 'user.email': [ { code: '[blank]user.email', message: 'You must specify either the [user.email] or [user.username] property. If you are emailing the user you must specify the [user.email].' } ], 'user.username': [ { code: '[blank]user.username', message: 'You must specify either the [user.email] or [user.username] property. If you are emailing the user you must specify the [user.email].' } ] }, generalErrors: [] } }

So basically I guess my best bet is to manually enforce uniqueness of username in my backend. But it could have been less cumbersome if I could delegate it to FusionAuth.

I guess what I am trying to emphasis here is the fact that just by saving username in user.data we will be able to have both username and email but applying rules such as uniqueness would require more manual labor. Cannot we just tell FusionAuth to make sure that user.data.username should be unique in that app or tenant?

Side note: Since my question is deviating from the OP I'll create a new post and reference this one.

@hanumant-sidraya Can you please clear up a few things.

It sounds like you have customers that have their own IdP. When you say "the customer has exposed the API for authentication.", what does that mean. They have an API that can confirm their identity?

If you have the APIs and authentication working with the customer's IdP, have you tried enabling the Two Factor Authentication for the user? Go to your user details screen in FusionAuth and then click 'Enable Two Factor' from the dropdown in the upper right hand corner?

For more details, you can refer to the Two Factor API documentation and the Enable Multi-Factor Authentication API documentation.

@didier I'm not 100% sure what you mean by "expose twoFactorId in frontend part". I'm assuming you mean give the user a way to input the code. So yes, you will have to allow them a method to input their code and then complete the login. Please see here for more information.

Hey @joshua,

Thanks for this Q&A, I have a question, what does this uniqueUsername mean and how it differs from username? E.g. code written in TS:

await fusionAuthClient.updateUser(id, { user: { uniqueUsername: username, }, }); // vs await fusionAuthClient.updateUser(id, { user: { username: username, }, }); How I register a user: await fusionAuthClient.register('', { sendSetPasswordEmail: true, skipVerification: false, registration: { applicationId, }, user: { email, lastName, firstName, memberships, fullName: `${firstName} ${lastName}`, username, }, }); Side note

I need username to be unique and I am utilizing @fusionauth/react-sdk's useFusionAuth hook. So basically IDK whether user.preferred_username is gonna be filled when I use uniqueUsername both in registration and updateUser or not.

And if the answer is negative* then should I manually write code to enforce uniqueness of username in my NestJS app?

*meaning if I use uniqueUsername in my frontend app preferred_username would be undefined

@didier hmm, I guess you can do it by registering user in your backend (get username, and password from the user and register a user with those). Then you can just exchange the plain text username, password for JWT tokens and attch them to response cookies. Something like this: https://github.com/kasir-barati/you-say/blob/main/apps/backend-e2e/src/utils/login.util.ts.

If you're using FusionAuth Typescript client you can do it like this: https://github.com/kasir-barati/you-say/blob/main/packages/backend/auth/src/lib/services/mobile-auth.service.ts#L71

@qwandery,

OR, perhaps a new concept is needed in FusionAuth -- "Organizations" if you will -- that allows for granting users with different permission sets inside the same Application.

You should feel free to open up a feature request here.

@rationem You could look at my backend app in this monorepo: https://github.com/kasir-barati/you-say

There I've implemented a NestJS custom backend app. BTW I have a question for you, right now my NextJS frontend build is broken and I do not know why, I mean I kinda know that it is because I am using @fusionauth/react-sdk and it needs to have access to document object but since during build it does not have that my build is defective. Any suggestion?

I also read this doc but it was not what I wanted since it was communicating directly with FusionAuth and in my case I do not want that 🙂.

Hey @dan,

Just wanted to point out a few things. First I have a custom Backend app and this doc does not cover that at all. It looked to me like it is communicating directly with FusionAuth which is not a good idea in my case (I am using mostly Client side components). So I switched gears and tried to use @fusionauth/react-sdk instead. It was working until I got busted with this broken build log. Any suggestion on how to fix my build since I guess it is related to NextJS and how we lack document at build time since it works just fine when I run the NextJS app in dev mode.

@qwandery @Alex-Patterson I think it is also very beneficial to focus on some implementation details such as how our logout endpoint should not validate JWT token otherwise user might receive a 401 JSON response.

In my case I was validating it in my backend app (NestJS) so I thought it should be OK but now that I am looking in the rearview mirror I think I can see why I should not have done that 😓.

Ah BTW, here I am using NextJS (standalone) + NestJS. So it is not SPA.