本文旨在深入探討華為鴻蒙HarmonyOS Next系統（截止目前 API12）在開發多語言電商平臺方面的技術細節，基於實際開發實踐進行總結。主要作為技術分享與交流載體，難免錯漏，歡迎各位同仁提出寶貴意見和問題，以便共同進步。本文為原創內容，任何形式的轉載必須註明出處及原作者。
在當今數字化時代，密碼安全是保障使用者資訊保安的重要防線。鴻蒙 Next 系統的密碼自動填充服務不僅提供了便捷的登入體驗，還具備一系列高階功能，以適應不同的應用場景和使用者需求。今天，我們將深入探討這些高階功能以及適配場景，為開發者提供全面的技術指導。
一、為應用新增自動生成高強度密碼的建議
（一）預設強密碼規則
當開發者未指定密碼規則，或指定的規則不符合規範時，密碼保險箱將依據預設規則生成強密碼。預設規則下的強密碼以字母開頭，包含大小寫字母和數字，長度固定為 16 位。這種預設設定旨在為使用者提供一個具有較高安全性的密碼生成方案，滿足大多數常見場景的需求。例如，系統可能生成類似於“AbCdEfG12345678”這樣的密碼，其中包含了大寫字母、小寫字母和數字的組合，具有一定的複雜性，能夠有效抵禦常見的密碼破解攻擊。
（二）開發者可自定義的強密碼規則
-
屬性介紹
開發者可以透過設定新密碼輸入框的 passwordRules 屬性來指定強密碼規則，強密碼中必須包含大寫字母、小寫字母、數字三種字元，同時可以按照以下方式對強密碼規格進行限定：- begin：表示生成的強密碼首位的字元型別，可選值包括“upper”（以大寫字母開頭）、“lower”（以小寫字母開頭）、“digit”（以數字開頭），若不填，則以任意字母或數字 0 - 9 開頭。例如，設定“begin:[upper]”將確保生成的強密碼以大寫字母起始。
- special：用於指定生成的強密碼是否包含特殊字元。當設定為“yes”時，強密碼中將至少包含一個特殊字元（如!@#$%^&*），且特殊字元不會出現在首位。例如，密碼規則“special:[yes]”會使生成的密碼更具複雜性。
- len：表示強密碼的長度，密碼保險箱允許設定的長度範圍為最小 12 位至最大 32 位。該屬性提供了三個關鍵字用於描述長度，分別為“fixedlen”（固定長度）、“minlen”（最小長度）、“maxlen”（最大長度）。開發者可以根據具體需求靈活設定，如“len:[fixedlen:15]”表示生成固定長度為 15 位的強密碼，“len:[minlen:13,maxlen:18]”則表示生成長度在 13 - 18 位之間隨機的強密碼。
-
樣例說明
以下是一些正確的自定義強密碼規則樣例及其釋義：
| 強密碼規則樣例 | 規則釋義 |
|---|---|
| begin:[upper],special:[yes],len:[maxlen:32,minlen:12] | 以大寫字母開頭，包含大小寫字母、數字、特殊字元，長度為 12 - 32 之間（包含 12 和 32）的隨機數值。 |
| begin:[lower],special:[yes],len:[maxlen:14] | 以小寫字母開頭，包含大小寫字母、數字、特殊字元，長度為 14 - 32 之間（包含 14 和 32）的隨機數值。 |
| begin:[digit],special:[yes],len:[fixedlen:15] | 以數字開頭，包含大小寫字母、數字、特殊字元，長度為 15 位。 |
- 錯誤用例
同時，我們也需要注意避免一些錯誤的規則設定，以下是一些錯誤用例及原因分析：
| 強密碼規則錯誤 | 錯誤原因 |
|---|---|
| begin:[uppper] | begin 屬性的取值“upper”拼寫錯誤。 |
| began:[upper] | begin 屬性拼寫錯誤。 |
| len:[15] | len 屬性語法錯誤，未使用三種長度關鍵詞。 |
| len:[fixedlen:15,maxlen:18] | len 屬性語法錯誤，fixedlen 與 maxlen 不可混用。 |
| len:[maxlen:15,minlen:18] | len 屬性引數值錯誤，maxlen 的取值不能小於 minlen。 |
二、系統可適配的場景
（一）不同輸入框組合下密碼保險箱的表現
-
兩個輸入框情況
- 當頁面上存在一個 Password / NEW_PASSWORD 型別輸入框，且同時存在 USER_NAME、Email、PhoneNumber 型別輸入框中的一種時，點選其中一個輸入框，會觸發賬號密碼填充提示；頁面跳轉時，自動彈出賬號密碼儲存提示框。例如，在一個登入頁面中，同時有使用者名稱輸入框（USER_NAME 型別）和密碼輸入框（Password 型別），使用者點選使用者名稱或密碼輸入框時，系統會自動檢測並提示填充已儲存的賬號密碼，登入成功跳轉頁面時，會詢問使用者是否儲存賬號密碼。
- 若頁面上僅有兩個 TextInput 輸入框，且其中一個為 Password / NEW_PASSWORD 型別，另外一個為非密碼型別時，同樣會觸發賬號密碼填充提示和儲存提示框邏輯。比如在一個簡單的密碼修改頁面，只有舊密碼輸入框（Password 型別）和新密碼輸入框（NEW_PASSWORD 型別），系統也能正確識別並提供相應的密碼填充和儲存功能。
-
多個輸入框情況
- 當頁面上有多個輸入框時，如果包含 InputType.USER_NAME / InputType.Email / InputType.PhoneNumber 其中一種或多種，以及 Password / NEW_PASSWORD 型別輸入框，點選其中一個輸入框，觸發賬號密碼填充提示；頁面跳轉時，自動彈出賬號密碼儲存提示框，且儲存賬號密碼時，優先儲存 USER_NAME 輸入框的內容作為賬戶名。例如，在一個複雜的註冊頁面，有使用者名稱輸入框（USER_NAME 型別）、郵箱輸入框（Email 型別）、密碼輸入框（Password 型別）和確認密碼輸入框（NEW_PASSWORD 型別），系統會根據使用者操作準確提供密碼填充和儲存服務。
三、自定義佈局下的適配建議
（一）登入、註冊、修改密碼頁面的佈局要求
-
登入頁面
應用在設定登入頁面時，需要將“使用者名稱/賬號名”和“密碼”放置在同一個介面，且使用者名稱輸入框應設定 type 屬性為 InputType.USER_NAME，密碼輸入框應設定 type 屬性為 InputType.Password。這樣的佈局設定能夠確保密碼自動填充服務準確識別並填充賬號密碼。例如，一個典型的登入介面可能包含一個使用者名稱輸入框和一個密碼輸入框，使用者在開啟登入頁面時，系統能夠自動檢測到輸入框型別，為使用者提供便捷的密碼填充服務。 -
註冊頁面
註冊頁面需要“使用者名稱/賬號名”和“新密碼”在同一個介面，並且新密碼輸入框的 type 屬性設定為 InputType.NEW_PASSWORD。同時，如果應用對密碼強度有特殊要求，可以根據開發者自定義的強密碼規則進行設定。例如，在一個社交應用的註冊頁面，使用者輸入使用者名稱後，在新密碼輸入框中可以根據設定的規則生成強密碼，提高賬號安全性。 -
修改密碼頁面
修改密碼頁面則要求“使用者名稱/賬號名”、“舊密碼”和“新密碼”在同一個介面。舊密碼輸入框使用 type 屬性為 InputType.Password，新密碼輸入框使用 type 屬性為 InputType.NEW_PASSWORD。例如，在一個電商應用的修改密碼介面，使用者需要先輸入使用者名稱和舊密碼進行身份驗證，然後設定新密碼，系統會根據輸入框型別和密碼規則提供相應的密碼填充和更新功能。
（二）登入、註冊失敗時的處理
當應用登入或註冊失敗時，透過頁面路由（router）跳轉返回，建議應用將 enableAutofill 屬性設定為 false，以避免儲存錯誤資訊。這是因為在登入或註冊失敗的情況下，使用者輸入的賬號密碼可能不正確或不完整，如果此時儲存這些資訊，可能會導致後續密碼自動填充出現問題，甚至可能引發安全隱患。例如，在一個金融應用中，如果使用者輸入錯誤的賬號密碼導致登入失敗，應用應在返回登入頁面時將 enableAutofill 屬性關閉，防止錯誤的賬號密碼被儲存到密碼保險箱中。
（三）將導致功能受限的佈局（舉例說明）
-
使用者名稱、密碼不在同一介面
如果登入頁面中使用者名稱和密碼分佈在不同的介面，密碼自動填充服務將無法正常工作。例如，某些應用可能將使用者名稱輸入放在一個頁面，點選下一步後才顯示密碼輸入頁面，這種佈局不符合密碼自動填充服務的要求，無法實現自動填充功能。 -
驗證碼登入
對於驗證碼登入的情況，如果頁面上沒有傳統的使用者名稱和密碼輸入框，而是透過驗證碼進行登入驗證，密碼自動填充服務不支援這種登入方式。例如，一些網站為了提高安全性，採用簡訊驗證碼登入，此時密碼自動填充服務無法發揮作用。 -
註冊頁面佈局不合理
在註冊頁面，如果使用者名稱和新密碼不在同一介面，或者缺少必要的輸入框型別，如只有使用者名稱和其他非密碼相關輸入框，將無法使用強密碼填充功能。例如，一個應用的註冊頁面只顯示了使用者名稱輸入框和一些個人資訊輸入框，沒有新密碼輸入框，那麼就無法為使用者提供強密碼生成和填充服務。
透過對鴻蒙 Next 密碼自動填充服務高階功能和適配場景的深入探索，我們可以看到該服務在提供強大功能的同時，也需要開發者在應用設計和開發過程中遵循一定的規範和建議，以確保密碼自動填充服務的正常執行和使用者體驗的最佳化。希望本文能夠幫助大家更好地利用這一服務，為使用者打造更加安全、便捷的應用環境。