Integrate accounts and login

1. If you sign up, the App Server initiates a request to create an account to the CommsEase Web Server using the API for creating an account. For more information, see Sign up.
2. After the account is successfully created, the CommsEase Web Server will return the account's token and other information, and the App Server manages the token.
3. If an app initiates a login request, the request is authenticated by your login logic first, such as account password verification.
4. If the verification succeeds, App Server returns the token to your app. The clients manages the token.
5. If the App uses the messaging service, the request must be verified using the token.
6. The login to the IM service is successful after verification, and the relevant APIs of the SDK can be called to perform the messaging service.

When using the messaging service, the App account and the CommsEase ID (accid) are separate. The accid is only used for the authentication and is irrelevant to the user information of the App. This concept is important for your development. It is recommended that the app user account and password are inconsistent with the accid and token used by CommsEase for login. The latter is not created by app users but allocated by the application server to ensure security.

Manual and automatic login

Manual login and automatic login are provided. The main differences between the two modes are:

• Whether the SDK will handle login failures.
• Whether the server will verify the security of the logged in device

First, manual logins are initiated by app users. If a login fails due to unfavorable network conditions or invalid passwords, the SDK will trigger the corresponding callbacks, stop the reconnection operation, and wait for the user to initiate a new login. The automatic login will reconnect after the login fails until the login is successful (except for the invalid password). Second, to ensure the security of the current user, the server will check the uniqueness of the device based on whether the current login is an automatic login. If the current login is an automatic login and the current login device is not the device for last login, then Its login is automatically blocked for security. You can also implement force login to ignore security checks. This is more suitable for the scenario where delay loading of communication modules without messaging: the automatic login is performed using the CommsEase ID issued by the CommsEase server. Handing login failures is not required.

Note that if you choose to log in automatically, when your app is activated in the background, it will be counted as one login and counted into the DAU for billing.

Reconnection

Once login is successful, IM SDK will handle cases where reconnections are required. No login is required for normal network conditions when clients reconnect to the server. The same mechanism is applied to chat rooms.

Login strategy

Instant messaging is applied in two major scenarios:

• Messaging apps that provides communications service, such as, messenger, and Wechat.
• Non-messaging apps that use communications as a support service. For example, apps that requires private messaging capabilities.

For messaging apps, the communication is the core capability. If an app fails to log in to CommsEase, the app cannot work. Therefore, apps of this type must log in to the app server and CommsEase server before running any business logic. The login is complete only when the app logs in to both the app server and CommsEase server. For non-messaging apps, loading the communication module can be delayed after the login to the app server. After the login is successful and the CommsEase ID and token issued by the server are obtained, automatic login is applied.

Account management

For a quick try, you can create and manage accounts in Account Management in the CommsEase console instead of calling the server API.

Note that the accounts created using the server will not appear in the account list of the CommsEase console. Reasons:

• The account list provided in the console includes only part of accounts for the app. These accounts allow you to integrate the service with client apps without backend development You can create test accounts in the CommsEase console and log in on the client for testing;

• The accounts created by the API are not displayed in the console for the user's privacy protection and account security. This prevents accounts from being disabled or other misoperations.

Integrate existing accounts

For applications that already have a large number of user accounts, you can create accounts on demand.

Considering a considerable proportion of zombie users or inactive users in the existing accounts, it is unnecessary to directly import the full amount when migrating to CommsEase. You can develop a logic that checks whether a user has an accid when the user triggers the behavior of using CommsEase service for the first time. If no account ID is created, follow the account creation process and automatically create an account ID in the background before login. Your users will only create CommsEase accounts when necessary, and all users created in CommsEase are valid and active users.

FAQ

How can I create accounts?

For testing purpose, you can log in to the CommsEase console and create testing accounts or create accounts by calling the corresponding server API. For applications in production, you can only create accounts by calling server API. For more information, see Server API.

Why can't I create an account using the client SDK but the server API?

The account system of CommsEase and the account system of the application are bound. Creating accounts by calling the server API can regulate the number of accounts created. Your app clients may be breached. Creating accounts using client SDK may impose fraudulent accounts risks.

Can the CommsEase account be deleted and use accids as the business accounts?

You cannot delete CommsEase accounts. If you do not need the account, you can disable the account by calling the corresponding server API. Using accid as the uid or account of your business system is not recommended. You can use random strings that are not associated with your business as the CommsEase accid when creating a CommsEase account. The business uid and the CommsEase accid are maintained on the app server.

• Benefits:

  • The business account system is protected and will not be directly exposed in the CommsEase service. Although your data is encrypted using CommsEase service, this practice can protect your data.
  • If you wants to delete the CommsEase account, just unbind the association relationship. If your wants to reset the status of an account, unbind the uid from accid and bind a new accid.

Will the account created by calling the server API appear in the CommsEase console?

No, accounts created by the server API do not appear in the CommsEase console.

• Reasons:
  • The account list provided in the console includes only part of accounts for the app. These accounts allow you to integrate the service with client apps without backend development You can create test accounts in the CommsEase console and log in on the client for testing;
  • The accounts created by the API are not displayed in the console for the user's privacy protection and account security. This prevents accounts from being disabled or other misoperations.