In-depth Exploration of the HarmonyOS Next Password Autofill Service: Advanced Features and Adaptation Scenarios

This article aims to deeply explore the technical details of the Huawei HarmonyOS Next system (up to API 12 as of now) in developing multilingual e-commerce platforms, and is summarized based on actual development practices. It mainly serves as a vehicle for technical sharing and communication. Mistakes and omissions are inevitable. Colleagues are welcome to put forward valuable opinions and questions so that we can make progress together. This article is original content, and any form of reprint must indicate the source and the original author.
In today's digital age, password security is an important line of defense for safeguarding user information security. The password autofill service of the HarmonyOS Next system not only provides a convenient login experience but also has a series of advanced features to adapt to different application scenarios and user needs. Today, we will explore these advanced features and adaptation scenarios in depth to provide comprehensive technical guidance for developers.

I. Suggestions for Adding Automatic Generation of High-Strength Passwords to Applications

(I) Default Strong Password Rules

When developers do not specify password rules or the specified rules do not conform to the specifications, the password vault will generate strong passwords according to the default rules. Under the default rules, strong passwords start with a letter, contain both uppercase and lowercase letters and numbers, and have a fixed length of 16 digits. This default setting aims to provide users with a password generation scheme with relatively high security, meeting the needs of most common scenarios. For example, the system may generate a password like "AbCdEfG12345678", which contains a combination of uppercase letters, lowercase letters, and numbers, has a certain level of complexity, and can effectively resist common password cracking attacks.

(II) Customizable Strong Password Rules for Developers

1. Attribute Introduction Developers can specify strong password rules by setting the passwordRules attribute of the new password input box. Strong passwords must contain three types of characters: uppercase letters, lowercase letters, and numbers. At the same time, the specifications of strong passwords can be limited in the following ways:     - begin: Indicates the type of the first character of the generated strong password. The optional values include "upper" (starting with an uppercase letter), "lower" (starting with a lowercase letter), "digit" (starting with a number). If not filled, it will start with any letter or number from 0 - 9. For example, setting "begin:[upper]" will ensure that the generated strong password starts with an uppercase letter.     - special: Used to specify whether the generated strong password contains special characters. When set to "yes", the strong password will contain at least one special character (such as!@#$%^&), and the special character will not appear at the first position. For example, the password rule "special:[yes]" will make the generated password more complex.     - **len*: Represents the length of the strong password. The password vault allows the length to be set within a range of a minimum of 12 digits to a maximum of 32 digits. This attribute provides three keywords to describe the length, namely "fixedlen" (fixed length), "minlen" (minimum length), "maxlen" (maximum length). Developers can set it flexibly according to specific needs. For example, "len:[fixedlen:15]" means generating a strong password with a fixed length of 15 digits, and "len:[minlen:13,maxlen:18]" means generating a strong password with a random length between 13 and 18 digits.
2. Example Explanation Here are some correct examples of custom strong password rules and their interpretations: | Strong Password Rule Example | Rule Interpretation | |---|---| | begin:[upper], special:[yes], len:[maxlen:32,minlen:12] | Starts with an uppercase letter, contains uppercase and lowercase letters, numbers, and special characters, and the length is a random value between 12 and 32 (including 12 and 32). | | begin:[lower], special:[yes], len:[maxlen:14] | Starts with a lowercase letter, contains uppercase and lowercase letters, numbers, and special characters, and the length is a random value between 14 and 32 (including 14 and 32). | | begin:[digit], special:[yes], len:[fixedlen:15] | Starts with a number, contains uppercase and lowercase letters, numbers, and special characters, and the length is 15 digits. |
3. Error Cases At the same time, we also need to pay attention to avoiding some incorrect rule settings. Here are some error cases and their reasons: | Strong Password Rule Error | Error Reason | |---|---| | begin:[uppper] | The value "upper" of the begin property is misspelled. | | began:[upper] | The begin property is misspelled. | | len:[15] | The len property has a syntax error. The three length keywords are not used. | | len:[fixedlen:15,maxlen:18] | The len property has a syntax error. fixedlen and maxlen cannot be mixed. | | len:[maxlen:15,minlen:18] | The len property has a parameter value error. The value of maxlen cannot be less than that of minlen. | ## II. Scenarios Adaptable by the System ### (I) Performance of the Password Vault under Different Input Box Combinations
4. Two Input Box Situations     - When there is a Password / NEW_PASSWORD type input box on the page and one of the USER_NAME, Email, PhoneNumber type input boxes at the same time, clicking on one of the input boxes will trigger the account password autofill prompt; when the page jumps, the account password save prompt box will be automatically popped up. For example, on a login page, there are both a username input box (USER_NAME type) and a password input box (Password type). When the user clicks on the username or password input box, the system will automatically detect and prompt to fill in the saved account password. When the login is successful and the page jumps, the user will be asked whether to save the account password.     - If there are only two TextInput input boxes on the page, and one of them is of the Password / NEW_PASSWORD type and the other is of a non-password type, the account password autofill prompt and save prompt box logic will also be triggered. For example, on a simple password modification page, there are only an old password input box (Password type) and a new password input box (NEW_PASSWORD type). The system can also correctly identify and provide the corresponding password autofill and save functions.
5. Multiple Input Box Situations     - When there are multiple input boxes on the page, if it contains one or more of InputType.USER_NAME / InputType.Email / InputType.PhoneNumber, as well as Password / NEW_PASSWORD type input boxes, clicking on one of the input boxes will trigger the account password autofill prompt; when the page jumps, the account password save prompt box will be automatically popped up, and when saving the account password, the content of the USER_NAME input box will be preferentially saved as the account name. For example, on a complex registration page, there are a username input box (USER_NAME type), an email input box (Email type), a password input box (Password type), and a confirm password input box (NEW_PASSWORD type). The system will accurately provide password autofill and save services according to the user's operations. ## III. Adaptation Suggestions under Custom Layouts ### (I) Layout Requirements for Login, Registration, and Password Modification Pages
6. Login Page When setting up the login page, the application needs to place the "username/account name" and "password" on the same interface, and the username input box should set the type property to InputType.USER_NAME, and the password input box should set the type property to InputType.Password. Such a layout setting can ensure that the password autofill service accurately identifies and fills in the account password. For example, a typical login interface may include a username input box and a password input box. When the user opens the login page, the system can automatically detect the input box types and provide a convenient password autofill service for the user.
7. Registration Page The registration page requires that the "username/account name" and "new password" be on the same interface, and the type property of the new password input box should be set to InputType.NEW_PASSWORD. At the same time, if the application has special requirements for password strength, it can be set according to the custom strong password rules of the developer. For example, on the registration page of a social application, after the user enters the username, a strong password can be generated in the new password input box according to the set rules to improve the security of the account.
8. Password Modification Page The password modification page requires that the "username/account name", "old password", and "new password" be on the same interface. The old password input box uses the type property of InputType.Password, and the new password input box uses the type property of InputType.NEW_PASSWORD. For example, on the password modification interface of an e-commerce application, the user needs to first enter the username and old password for identity verification, and then set the new password. The system will provide the corresponding password autofill and update functions according to the input box types and password rules. ### (II) Handling of Login and Registration Failures When the application login or registration fails, and the page is routed (router) back, it is recommended that the application set the enableAutofill property to false to avoid saving incorrect information. This is because in the case of login or registration failure, the account password entered by the user may be incorrect or incomplete. If these information are saved at this time, it may cause problems with subsequent password autofill and may even lead to security risks. For example, in a financial application, if the user enters incorrect account password and the login fails, the application should turn off the enableAutofill property when returning to the login page to prevent the incorrect account password from being saved to the password vault. ### (III) Layouts That Will Limit the Function (Examples)
9. Username and Password on Different Interfaces If the username and password are on different interfaces on the login page, the password autofill service will not work normally. For example, some applications may place the username input on one page and display the password input page only after clicking the next step. This layout does not meet the requirements of the password autofill service and cannot implement the autofill function.
10. Verification Code Login For the case of verification code login, if there are no traditional username and password input boxes on the page but login verification is carried out through verification codes, the password autofill service does not support this login method. For example, some websites use SMS verification code login to improve security. At this time, the password autofill service cannot play a role.
11. Unreasonable Registration Page Layout On the registration page, if the username and new password are not on the same interface, or if there are missing necessary input box types, such as only having the username and other non-password related input boxes, the strong password autofill function cannot be used. For example, on the registration page of an application, only the username input box and some personal information input boxes are shown, without a new password input box. Then, the strong password generation and autofill service cannot be provided for the user. Through the in-depth exploration of the advanced features and adaptation scenarios of the HarmonyOS Next password autofill service, we can see that while the service provides powerful functions, developers also need to follow certain norms and suggestions in the application design and development process to ensure the normal operation of the password autofill service and the optimization of user experience. We hope that this article can help everyone make better use of this service and create a more secure and convenient application environment for users.