Posts made by akoskm

@altear147 I encountered this behavior today when I tried to update the username for a user:

await getFusionAuthClient(tenantId).updateUser(userId, {
    user: {
      username,
    },
  });

To my surprise (but probably only the lack of knowledge), this set theusername of the user as specified but also deleted the email just as you described.

I was thinking, okay, let's move on and don't touch username and specify firstName as the only key for the update:

await getFusionAuthClient(tenantId).updateUser(userId, {
    user: {
      firstName,
    },
  });

but then I received this error:

Which I also didn't expect, since I assumed the userId uniquely identifies a user and I don't have to supply more fields to help FusionAuth identify it.

After supplying the exact same things as you did:

await getFusionAuthClient(tenantId).updateUser(userId, {
    user: {
      email: email as string,
      firstName: firstName as string,
      lastName: lastName as string,
      mobilePhone: mobilePhone as string,
    },
  });

my user object is getting updated. To clarify, the email input is disabled on my form, and users can only enter first name, last name, and mobile phone.

You can find the complete code here: https://github.com/akoskm/saas/blob/main/app/routes/team_.%24userId.edit.tsx

Hope this helps.

@jarrod We just rolled out such an app to one of our clients, and I'm happy to share my experiences with you.

Do we whitelist a large amount of callback URLs?

We haven't. Same as in your case, the user registers through a self-serve sign-up form where they enter the tenant details, such as the subdomain. During tenant creation on our backend, we simply construct the new tenant URLs for login and Oauth (we configure Oauth because we have a desktop app connecting to this same backend).

  const newFusionAuthAppConfig = {
    name: `"${organizationName}"'s Project`,
    oauthConfiguration: {
      ...blueprintAppConfig.oauthConfiguration,
      enabledGrants: [GrantType.authorization_code, GrantType.refresh_token],
      authorizedRedirectURLs: [`${newAppUrl}/api/oauth-redirect`],
      logoutURL: `${newAppUrl}/api/logout`,
    },
    loginConfiguration: blueprintAppConfig.loginConfiguration,
  };

So when the new tenant is set up, it already has everything tenant-specific. We use the default tenant as the blueprint for some of our configurations - blueprintAppConfig.

Do we create an Application per custom domain? (Does this mean we have to sync users?)

This is what we did, but I guess it depends on your use case. For us, it was important that one user can register on different subdomains with the same email.

Do we redirect to the main app and perform some kind of sidechannel/backchannel SSO iframe magic?

I can assure you there's no magic once you correctly set up the tenant creation. The entire front end (React here) works the same as before. Most of the "magic" on the backend is simply realizing from which tenant the request came and constructing a tenant-specific Fusion Auth client to retrieve tenant-specific user details, apps, etc.

FusionAuth's official documentation on multitenant setup was an immense help to us.

@egli If you're using TypeScript/JavaScript you can implement a simple page with inputs and call

  const newUserFields = {
    firstName: form.firstName,
    lastName: form.lastName,
  };

  await fusionAuthClient.patchUser(user.id, {
    user: newUserFields,
  });

or use the Update user REST API to pass firstName and other fields.

@jswgger007 Is it possible that you have a .env.local that would overwrite the default values in .env?

Is this issue happening when you run the app locally or in some other environment?

Hi @dan, Patrik is my colleague who tried to make this work but had no success. Could you take a look at his post below? Thank you!

Hi!

Is it possible to create an admin account with FusionAuth Admin Interface access from the Kickstart file.

Here's my kickstart file:

{
  "variables": {
    "adminEmail": "cypress@example.com",
    "user1Email": "rob@example.com",
    "password": "hello123",
    "defaultTenantId": "30663132-6464-6665-3032-326466613934"
  },
  "apiKeys": [
    {
      "key": "#{ENV.FUSION_AUTH_API_KEY}",
      "description": "Standard development API key"
    }
  ],
  "supportId": "5acfd1b6-f687-ae13-8ffd-1900200c9a77",
  "requests": [
    {
      "method": "POST",
      "url": "/api/application/#{ENV.SECRET_FUSIONAUTH_CLIENT_ID}",
      "body": {
        "application": {
          "name": "Project Secret",
          "oauthConfiguration": {
            "clientSecret": "#{ENV.SECRET_FUSIONAUTH_CLIENT_SECRET}"
          },
          "roles": ["user", "admin"]
        }
      }
    },
    {
      "method": "POST",
      "url": "/api/user/registration/ace26aa5-0fe9-4672-bc5f-dfe198f4955d",
      "body": {
        "user": {
          "email": "#{adminEmail}",
          "password": "#{password}"
        },
        "registration": {
          "applicationId": "#{ENV.SECRET_FUSIONAUTH_CLIENT_ID}",
          "roles": ["user", "admin"]
        }
      }
    },
  ]
}

My understanding was that it should be enough to add the "admin" role to the user to be able to access the admin interface.

However, when I try to log in with cypress@example.com:hello123 - a user with the "admin" role - I'm getting this screen:

Thanks!