Create a new user in MemberJunction automatically

Automatically create a new user in MemberJunction whenever a new user is added to your authentication provide (Auth0, etc)

In many instances it is desirable to automatically add a new user to MJ whenever a user is authenticated by your Auth provider. MemberJunction supports plug-ins for any type of authentication provider and has built-in support for Auth0 and MSAL. In the case of externally facing applications, it is often desirable to auto-create a new MemberJunction user whenever the user is created inside the Auth provider (e.g. via a "Sign Up" type of page).

The steps to do this are straightforward:

  1. Within the MJAPI project, go to the config.json file and within that file edit the userHandling section
"userHandling": {
    "autoCreateNewUsers": false,
    "newUserLimitedToAuthorizedDomains": false,
    "newUserAuthorizedDomains": [],
    "newUserRoles": [],
    "updateCacheWhenNotFound": true,
    "updateCacheWhenNotFoundDelay": 5000,
    "contextUserForNewUserCreation": "[email protected]"
}

You can see in the above the default setting is to not auto-create new users. You simply change that to true and then populate the rest of the settings:

  • newUserLimitedToAuthorizedDomains - if set to True, then the list of domains noted in the newUserAuthorizedDomains will be used to determine if the new user is created or not. If this setting is set to false then the newUserAuthorizedDomains list will be ignored
  • newUserAuthorizedDomains - if you would like to narrow the scope of auto-created new users, you can specify an array of domains that will be allowed to automatically create User records in MJ. Keep in mind this is not the way you should secure your app. You should determine access to the overall app via your authentication provider. Here you are simply specifying which domains from already authenticated users would auto-create records in the MJ User table. For local testing and development, be sure to include localhost as a domain
    The format for this setting is an array of strings, and can include exact matches for domains as well as wildcards as shown below
    "newUserLimitedToAuthorizedDomains": [
      "google.com",
      "member*.com",
      "memberjunction.*",
      "*soft.com"
    ]
    
  • newUserRoles - you can specify any number of roles - which map to the Name of the Role in MJ that you want to automatically add the newly created user to. Each role should be a separate entry in the list, rather than a comma-delimited array of roles.
  • updateCacheWhenNotFound - is a setting that will automatically refresh the user cache in the MJAPI server whenever a user is not initially found. If you have another service creating user records in your MJ database, you might often find a timing issue between services and so this allows for a refresh of the user cache. You can use this setting independent of autoCreateNewUsers setting.
  • updateCacheWhenNotFoundDelay - specifies the number of milliseconds to delay the refresh whenever a user cache update is going to be performed. This works in unison with the updateCacheWhenNotFound setting and is used to delay the refresh to help with synchronization issues.
  • contextUserForNewUserCreation - in MemberJunction server side operations, a "context user" is required for all operations. In the case of most API requests, that context user is the authenticated user. However when creating a new user the new user can't be the context user because it doesn't yet exist. This setting controls which context user the server will use for setting up the new user record in the database.
  1. The above will handle auto-creating a new user without any further work. In many cases, you might want to have additional logic get executed whenever a new user is created. There are several ways to do this including building an entity sub-class for the User entity, more on that here. However, if you want to simply do this inside the MJAPI for that specific event, you can do it by creating a subclass of the NewUserBase class within MemberJunction as described in this code recipe.
  2. Refer to the sample.config.json file to see how these fields may be populated in a local working environment.