Custom database function template

Authing supports connecting to the developer's own independent database through a custom database operation script. We support mainstream databases including PostgresQL, MySQL, MongoDB, and Sql Server. At the same time, you can also choose not to directly expose database connections to the outside world, but encapsulate the interface and provide it to the Authing server. If you want to save the user's core data in your own database, or your system has an old database, you need to lazily migrate to Authing in a non-stop manner, you can achieve this way.

There are two different modes for custom databases, and you can choose the appropriate mode according to your business needs:

• Lazy migration of users: This mode of migrating users is called lazy migration. In simple terms, the principle is as follows: At the beginning, all the original user data is in your database. When the user is the first When logging in with Authing for the second time, Authing will find and verify the user in your database through the custom database script you configured. If successful, the user will be migrated to Authing; when the user logs in for the second time, Authing will be used. The database verifies it; when all users log in at least once, it means that the migration to the cloud is complete. For details, please see: Use a custom database to implement lazy migration of users (opens new window).
• Fully use custom database: In this mode, user data is always stored in your database, and Authing will never save your user data. In order for the system to work properly, you need to implement a complete user add, delete, modify, and check script.

Authing provides the following custom database operation scripts:

• Login
• Find User
• Create User
• Modify User Information
• Verify Password
• Delete User
• Get User List

Script execution

As described in Custom Database Connection Overview, the custom database connection type allows you to configure the operation script to use when connecting to the legacy identity store. Every action script is essentially a named JavaScript function, which passes many parameters. The name of the function and the parameters passed depend on the script.

Execution environment

The authentication of custom database scripts is executed in a highly "secure, isolated cloud environment, supports the asynchronous feature of JavaScript, and you can use the latest async/await syntax.

Node Module

You can import the following Node modules:

• pg (opens new window)
• bcrypt (opens new window)
• axios (opens new window)
• lodash (opens new window)
• mongodb (opens new window)
• mysql2 (opens new window)
• mysql2/promise (opens new window)

Example:

const bcrypt = require(`bcrypt`);
const valid = await bcrypt.compare(`passw0rd`, user.password);

Environment variables defined by UserPool

• env.DB_CONNECTION_URI: The database connection string you configured, usually in a format similar to postgres://postgres:postgres@localhost:5432/database-name.
• env.DB_HOST, env.DB_PORT, env.DB_USERNAME, env.DB_PASSWORD, env.DB_DATABASE: The database host, port, user name, password and database name configuration of the database you own. -Other variables you configure in User Pool-Settings-Environment Variables.

Limits

Authing custom database script supports the asynchronous feature of JavaScript, and can use such as Promise (opens new window), and also supports async/await syntax. The Authing cloud environment usually has an execution limit of 20 seconds, and resources are reclaimed after timeout. Recycling resources due to this restriction will eventually result in an error condition being returned.

Complete the script

The return value of your script will be the agreement with the Authing server. You need to return data in a specific format according to the agreement, otherwise unknown errors may occur. The operation script should be completed immediately after the return statement, and any other operations should be avoided.

If the operation uses asynchronous processing, you must postpone the call to the return statement until the asynchronous processing is completed (for example, using await, before your operation is executed).

At the same time, please remember to close the connection to the database when the script is executed, such as calling client.end(). For example, it can be executed in try/finallly to ensure that it will always be executed:

try {
  const result = await client.query("YOUR QUERY");
} finally {
  // NOTE: always call `client.end()` here to close the connection to the database
  client.end();
}