Splync v1.1 推出電子郵件驗證功能

當您註冊 Splync 時，系統會要求您輸入電子郵件地址和密碼。如我在之前的文章中介紹過，Splync v1.0 已經包含基本的安全措施。您的數據傳輸是透過 HTTPS 保護的。我們的伺服器使用 SSH 進行保護，除了開發者外，沒有人能訪問。您的密碼從未以明文保存，而是以雜湊形式存儲在資料庫中，無人能解碼。然而，v1.0 的一個秘密是它在帳戶創建過程中沒有電子郵件驗證。Splync 作為一個 MVP（最小可行產品）發布時沒有這個功能，因為該應用程序當時只有我的朋友知道它的存在。在 v1.0 中，應用程序僅檢查輸入的電子郵件是否在字母串之間包含一個 “@”，以及在現有帳戶中是否唯一。

如果一個應用允許用戶在未驗證身份的情況下創建帳戶，可以想像有人會用別人的電子郵件地址來創建帳戶。這正是可能發生的情況。雖然這不意味著您的數據會洩露，但如果您的電子郵件地址已被使用，則您無法用自己的電子郵件註冊。此外，還可能有人用完全虛構的電子郵件地址創建帳戶。這一開始看似不嚴重，但一旦開發者試圖向該用戶收費或聯繫時，就會變成災難。我甚至不知道那個人是誰！因此，電子郵件驗證是 Splync 的下一步。

在 Splync v1.1 中，當新用戶註冊時，應用會自動向他們輸入的地址發送電子郵件。這封電子郵件包含一個唯一的自動生成的驗證鏈接。用戶點擊該鏈接後，即可確認他們確實能夠訪問該電子郵件帳戶。一旦驗證成功，伺服器便會激活用戶的帳戶，並將其存儲在資料庫中，作為有效和已驗證的用戶。是不是很熟悉？這一過程確保 Splync 中的每個帳戶都屬於真正可以聯繫到的人——這是構建可信任社群的小但重要的一步。讓我們更深入地了解從技術角度如何實現這一流程。

Splync 的後端使用 Python/FastAPI，移動應用則由 SwiftUI 構建。應用只處理用戶界面，而驗證邏輯和敏感憑證則安全地保留在伺服器上。在 v1.1 中，我們在“未驗證用戶”和“驗證用戶”之間添加了一個標準的電子郵件驗證步驟。當新用戶註冊時，應用會將輸入的數據發送到伺服器。伺服器使用 MariaDB 資料庫。它將用戶作為未驗證狀態存入資料庫。密碼以雜湊形式保存，但帳戶尚未激活。此時，伺服器還會生成一個帶有過期時間的唯一驗證令牌。接著，使用 SMTP（簡單郵件傳輸協議）伺服器，伺服器發送包含安全一次性鏈接的驗證電子郵件。當用戶打開鏈接時，伺服器會檢查令牌是否有效且未過期。一旦驗證成功，帳戶便可激活，用戶可正常從應用登入。這保持了身份驗證的安全性和輕量化。

如果這些聽起來像密碼，別擔心——它們只是讓系統運行起來的工具。想像一下 Splync 的註冊流程就像客服中心驗證某人的身份。“可以告訴我您的姓名和電子郵件地址嗎？” SwiftUI，前台的友好接待員問道。您告訴她您的詳細信息，她說：“能稍等一下嗎？” 她立即將它們轉發給 FastAPI，辦公室內部電話系統。FastAPI 將她連接到 Python，負責驗證的後台專家。Python 查詢 MariaDB 客戶資料庫，安全地記錄您的信息——標記您的狀態為“未驗證”。然後 Python 要求 SMTP，外部信使，發送一封含有安全鏈接的確認電子郵件給您。當您點擊該鏈接，Python 驗證鏈接有效性並更新您在 MariaDB 中的記錄為“已驗證”。最後，FastAPI 讓接待員知道您的身份已確認，您的帳戶現在已激活。這些部分共同讓 Splync 的驗證過程既人性化又安全。

電子郵件驗證看似小功能，卻改變了信任的一切。它標誌著 Splync 從朋友間的個人項目轉變為任何人都可以自信加入的公共應用。通過 SMTP 发送驗證鏈接，甚至像是 Splync 與新用戶初次握手。在幕後，這個功能為未來的改進奠定了基礎——密碼重設、多因素認證和賬戶恢復。每層安全都建立在之前的基礎上。隨著電子郵件驗證的加入，Splync v1.1 向前邁出了重要的一步——讓共享支出管理不僅便利，而且值得信賴。