Ahhhhhh, this error is getting on my nerves: You must specify either the [user.email] or [user.username] property. If you are emailing the user you must specify the [user.email]

The thing is that I am setting the user's email to enable them login and then inside data object I am setting a username for the future use, but as of now it is kinda random and automatically generated at the registration time.

So why the heck is FusionAuth SDK for Typescript returns a client response with this error is a mystery for me.

It should not do it under normal circumstances, according to my understanding you can only use email or username, and I am setting email as the way to login but username is inside the data and that should not interfere with anything IMO.

I am trying to update this user that was created automatically with Terraform:

resource "fusionauth_user" "you-say-temp-user" {
  tenant_id                = fusionauth_tenant.you-say-tenant.id
  email                    = "souma.kazuya@you-say.com"
  first_name               = "Souma"
  last_name                = "Kazuya"
  password                 = "souma.kazuya"
  skip_verification        = true
  password_change_required = false
  data = jsonencode({
    username : "souma_kazuya"
  })
}

And here is the TS code that I am using to update it, as you can see I am not even touching username:

await this.fusionAuthClient.updateUser(id, {
  user: {
    lastName: updateUserInfoDto.lastName,
    firstName: updateUserInfoDto.firstName,
  },
});

It would be really great if someone could leave a comment setting myself aside ありがとう.

Coming back to this thread to update you on something really weird, FusionAuth is throwing an error when I try to have email and user.data.username. I thought FusionAuth really do not care about what is inside the data. Or maybe I am misconfiguring somethings .

It's error message: You must specify either the [user.email] or [user.username] property. If you are emailing the user you must specify the [user.email].

I can also think of one ugly solution which is not very pleasant for the users and that would be generating usernames by concatenating firstName, lastName and a random hexadecimal string.

It seems like I do not have any mean to implement this in FusionAuth, I search for a way to define new constraints in DB for user.data field but no luck.

Then the other option is a vulgar way of doing it, fetching all users and then looping over users and comparing the user.data.username with the new one. It is not gonna work in a medium-size or large user base app.

I can think of one more option which is saving all usernames in my MongoDB database which can work but is not what I would volunteer for it.

Any suggestion?

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?

GH issue: https://github.com/FusionAuth/fusionauth-issues/issues/185

username, and email uniqueness.

We wanna let users to register with unique usernames, and email addresses. I know that we can store the email/username in the user.data field, which is not required to be unique. And we know that we cannot specify username and email at the same time. Look at this error message you'll get when you try to specify both:

{
  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: []
  }
}

I was trying to update a user with following code:

await fusionAuthClient.updateUser(id, {
  user: {
    lastName: updateUserInfoDto.lastName,
    firstName: updateUserInfoDto.firstName,
    uniqueUsername: updateUserInfoDto.username,
  },
});

So here is a similar Q&A: https://fusionauth.io/community/forum/post/3055

Qustion

I am trying to emphasis 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 work. Cannot we just tell FusionAuth to make sure that user.data.username should be unique in that application or tenant?

I really do not like to check it manually in my backend considering how costly and inefficient it would be;

1. Send an HTTP req to FusionAuth API to fetch all the users.
2. Loop over them to verify user.data.username is not equal to the one that is entered by the user.
3. Update user.

Or at least that's how I though about its implementation.

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.

Thanks @mark-robustelli for your pointers, although I know how we can leverage lambda functions to customize our JWT tokens but I dunno if we can use them to change what GET /me endpoint returns. That's part of the reason I opt to develop my own backend to communicate with FusionAuth.

Hey @dan,

Would you mind if I ask you to differentiate between uniqueUsername and username both in updateUser and register in FusionAuth Typescript Client?

await fusionAuthClient.updateUser(id, {
  // ...
  user: {
    uniqueUsername: username,
  },
});
await fusionAuthClient.updateUser(id, {
  // ...
  user: {
    username: username,
  },
});
await fusionAuthClient.register('', {
  // ...
  user: {
    username,
  },
});
await fusionAuthClient.register('', {
  // ...
  user: {
    uniqueUsername,
  },
});

Questions

1. If I use username instead of uniqueUsername, then should I enforce uniqueness manually in my NestJS app?
2. If I use uniqueUsername then will I have access to it as preferred_username returned by FusionAuth?

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

We have an open issue for it in @fusionauth/react-sdk: https://github.com/FusionAuth/fusionauth-javascript-sdk/issues/99. But it might not be the answer if you are looking for an answer that utilizes next-auth.

Like I mentioned before I tried the docs and I ended up with another bump along the way. It seems like FusionAuth integration with NextJS is not the best idea. Maybe it's time to switch gears and try SPAs ?

@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

Not sure exactly if this is what you need but probably you can implement your own backend app to communicate with FusionAuth however you see fit. Just like what I did here in NestJS. Then in my react app I have a normal form and then sends an HTTP request to my backend endpoint. So in other word I am not using startLogin helper function.

Yes, I know it is not angular. But just to light your creativity I thought it is a good idea too look at it from a different perspective.

BTW I appreciate it if you could give my repo a star if it did help you.

I've also read:

1. https://fusionauth.io/community/forum/post/5781
2. https://fusionauth.io/community/forum/post/5782

But none of them where what I needed. Though I jot down some comments there too .

Hi folks,

I've been reading https://fusionauth.io/docs/quickstarts/quickstart-javascript-nextjs-web and then I realized that it is communicating directly with FusionAuth. Which means that we where providing it our client secret. I am cool with that idea however I was wondering if that does mean that I can now wipe out my backend RESTful APIs since they are not needed anymore. I mean I can keep them or at least the ones for mobile.

But in general I was not sure anymore about these endpoints.

I guess it boils down to whether I need full control over generating JWT tokens and things like that. Or maybe I am missing some points .

I also loved the @fusionauth/react-sdk but like I mentioned it is not working and I dunno how to fix it either. I appreciate it if you could help me with that too.

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