Last Updated on : 2022-02-17 05:45:20download
Terminology | Meaning |
---|---|
Brand Account | This account does not support registration This account will be bound to the corresponding OEM SaaS login domain, the master account provided when purchasing OEM SaaS from Tuya Smart. |
Enterprise master account | The accounts registered by developers independently are all enterprise master accounts, which have all privileges within the enterprise and can create/delete projects. |
Enterprise sub-account | SaaS side login to the enterprise master account can create enterprise sub-account, assign privileges to it, and can limit access to specific functions. |
The function of main account registration on app side is not supported for now, you need to open enterprise main account in SaaS platform.
The account system is designed as a model where one account corresponds to multiple merchants. However, the current commercial lighting restriction is one-to-one, and one account only corresponds to one unique merchant. So there is no need to pass in the merchant code when logging in, and the backend can query the unique merchant corresponding to the current account.
Login methods support.
Three-party system authorization login: This method needs to be used with Commercial Lighting Cloud API
Authorization process
Usage Scenarios
void loginByTicket(String ticket, ITuyaUserResultCallback<User> listener);
Parameter description
parameter | description |
---|---|
ticket | get ticket by authorization process |
Sample code
TuyaOSUser.getUserInstance().loginByTicket(content, new ITuyaUserResultCallback<User>() {
@Override
public void onSuccess(User user) {
Log.e(TAG, "Login successful")
}
@Override
public void onError(String code, String error) {
Log.e(TAG, "Failed to login: " + error)
}
});
This scenario is applicable when you forget your password: you need to retrieve it/reset it. The steps are the same for both, but you need to verify the permission before querying the merchant list.
So it is divided into three steps, first get the verification code to retrieve the password, pass the verification code into the list of merchants, get the corresponding individual merchants to perform the password retrieval party to change the password.
Account basic information storage/clearing are handled internally in sdk, so developers don’t need to care about the security and synchronization of account information.
After successful login, sdk will cache the basic account information, and after successful logout, sdk will also clear the current account cache data, so developers only need to handle their own business logic after successful callbacks.
Enterprise master account does not support account cancellation function at the moment, please submit work orders in IOT platform for manual review
At present, the merchant account system does not support the function of setting binding information for the account.
For example, the account registered by cell phone number is bound to mailbox, or the account registered by mailbox is bound to cell phone number.
Account inherent attributes (account name, account role, etc.) will be returned as account attributes after successful login, while user additional attributes (nickname, avatar, etc.) will not be returned after successful login and need to be retrieved through Get User Information for additional queries.
Also Get user information can be used in the scenario of doing multi-side data synchronization, where the other side modifies additional user attributes and synchronizes the latest data through this method.
Commercial lighting business currently supports Modify user avatarand Modify nickname,
both only need to deal with UI logic, subsequent data caching, etc. are handled within the sdk, no additional synchronization is required by the developer.
Is this page helpful?
YesFeedbackIs this page helpful?
YesFeedback