Quy tắc xác thực dùng chung cho web và mobile

Tại sao xác thực bị lệch

Xác thực bị lệch vì một lý do đơn giản: các form web và mobile thường được xây dựng vào những thời điểm khác nhau bởi những người khác nhau. Một nhóm thêm một quy tắc nhanh trên website, nhóm khác sao chép phiên bản cũ vào app, rồi mọi người tiếp tục với phần việc của mình.

Lúc đầu, khác biệt có vẻ nhỏ. Rồi một thay đổi làm nó lộ ra. Mật khẩu giờ cần 12 ký tự thay vì 8. Số điện thoại cần mã quốc gia. Một trường từng là tùy chọn giờ trở thành bắt buộc. Nếu chỉ một client được cập nhật, cùng một khách hàng có thể nhập được dữ liệu hợp lệ trên thiết bị này nhưng bị chặn trên thiết bị khác.

Đó là lý do quy tắc xác thực dùng chung quan trọng. Nếu không có chúng, mỗi client sẽ trở thành một phiên bản chân lý khác nhau.

Lệch trông như thế nào trong thực tế

Form đăng ký cho thấy vấn đề rất nhanh. Trên website, "tên công ty" có thể là tùy chọn. Trong app mobile, nó có thể vẫn bắt buộc vì màn hình đó được xây dựng từ cả tháng trước. Người dùng điền cùng một form hai lần, nhận hai kết quả khác nhau, và nghĩ rằng sản phẩm bị hỏng.

Điều này thường xảy ra khi các quy tắc bị sao chép vào nhiều nơi và cập nhật thủ công. Thời điểm phát hành làm tình hình tệ hơn. Một thay đổi trên web có thể lên sóng hôm nay, trong khi sửa trên mobile phải chờ bản phát hành tiếp theo.

Sự không khớp thường xuất hiện ở những chỗ cơ bản: trường bắt buộc, kiểm tra định dạng, và giới hạn nghiệp vụ như tuổi, kích thước đơn hàng, hay quy tắc giảm giá. Nhóm hỗ trợ cuối cùng phải giải thích tại sao một màn hình chấp nhận giá trị mà màn hình khác từ chối. Dần dần, người dùng ngừng tin vào thông báo lỗi, và các nhóm ngừng tin vào các bản phát hành của họ.

Bản thân quy tắc hiếm khi là vấn đề thật sự. Vấn đề là cùng một quy tắc sống ở quá nhiều nơi.

Những gì nên giống nhau ở mọi nơi

Nếu một form hành xử khác trên web và khác trên mobile, người dùng sẽ nhận ra ngay. Cách an toàn nhất là quyết định quy tắc nào là phổ quát và giữ chúng giống nhau trên mọi client.

Bắt đầu từ cơ bản. Một trường không nên là bắt buộc trên thiết bị này và là tùy chọn trên thiết bị khác trừ khi có lý do sản phẩm rõ ràng. Kiểm tra định dạng cũng nên khớp. Email, điện thoại, ngày tháng và các trường tương tự nên theo cùng một mẫu ở mọi nơi. Ngay cả một khác biệt nhỏ, như một client cho phép dấu cách trong số điện thoại còn client khác từ chối, cũng gây nhầm lẫn.

Giới hạn độ dài và ký tự cho phép cần được xử lý giống nhau. Nếu tên người dùng chấp nhận 30 ký tự trên mobile nhưng chỉ 20 trên web, người dùng có thể lưu dữ liệu mà client khác không thể chỉnh sửa sau này. Vấn đề tương tự xảy ra với tên, ghi chú, mã và ID.

Quy tắc nghiệp vụ cũng quan trọng không kém. Nếu người dùng phải trên một tuổi nhất định, thuộc vùng hỗ trợ, hoặc có trạng thái tài khoản nhất định, các kiểm tra đó nên hoạt động giống nhau trên mọi màn hình.

Cách diễn đạt không cần phải hoàn toàn giống nhau ở khắp nơi, đặc biệt trên màn hình mobile nhỏ hơn, nhưng ý nghĩa phải nhất quán. Nếu một app nói "Nhập ngày hợp lệ" và app khác nói "Ngày không được hỗ trợ", người dùng có thể cho rằng quy tắc khác nhau ngay cả khi không phải vậy.

Một bài kiểm tra đơn giản hiệu quả ở đây: nếu người dùng nhập cùng dữ liệu trên web và mobile, họ nên nhận cùng kết quả và hướng dẫn cơ bản giống nhau về cách sửa lỗi.

Để backend đưa ra quyết định cuối cùng

Phản hồi nhanh ở frontend hữu ích, nhưng không bao giờ là lời phán cuối cùng. Backend luôn phải quyết định dữ liệu có hợp lệ hay không.

Web và mobile vẫn nên bắt các lỗi hiển nhiên sớm. Chúng nên báo các trường bắt buộc còn thiếu, định dạng email sai, ngày không hợp lệ, và các giá trị rõ ràng ngoài phạm vi. Điều đó giúp tiết kiệm thời gian và giúp người dùng sửa trước khi bấm Gửi.

Nhưng backend thấy toàn cảnh. Nó có thể kiểm tra quy tắc nghiệp vụ gắn với dữ liệu sống, trạng thái tài khoản, quyền hạn, tồn kho, hoặc các bản ghi bị người khác thay đổi ngay trước đó. Một mã khuyến mãi có vẻ hợp lệ trên điện thoại, nhưng server biết nó đã hết hạn hoặc đã bị dùng.

Để quy tắc dùng chung hoạt động tốt, backend nên trả về lỗi ở định dạng mọi client đều hiểu được. Tránh các trả lời mơ hồ như "Dữ liệu không hợp lệ." Hãy dùng mã lỗi hoặc tên quy tắc ổn định kèm theo một thông điệp rõ ràng.

Một vài ví dụ:

• required cho trường thiếu
• invalid_format cho email hoặc mẫu điện thoại sai
• out_of_range cho giá trị vượt giới hạn
• not_allowed cho kiểm tra dựa trên quyền hoặc trạng thái
• already_exists cho email, tên người dùng hoặc ID trùng lặp

Những tên đó nên giữ ổn định giữa các client. Các khác biệt nhỏ như email_invalid ở app này và invalid_email ở app kia gây ra lỗi không cần thiết.

Một bài kiểm tra backend tốt thì đơn giản: nếu ai đó bỏ qua UI và gửi yêu cầu thẳng tới API, cùng dữ liệu xấu vẫn phải bị từ chối vì cùng lý do.

Tạo một nguồn chân lý duy nhất

Cách sửa sạch nhất là một cuốn sổ quy tắc chung. Nếu mỗi nhóm viết validation trong từng form web và từng màn hình mobile, các quy tắc sẽ bị lệch. Quy tắc dùng chung hoạt động tốt hơn khi quy tắc được định nghĩa một lần và mọi client theo cùng định nghĩa đó.

Nguồn chia sẻ này có thể là một schema, một model backend, hoặc một cấu hình sản phẩm trung tâm. Định dạng chính xác ít quan trọng hơn thói quen. Định nghĩa trường một lần trước khi bất kỳ ai xây màn hình. Giữ tên trường, kiểu dữ liệu, trạng thái bắt buộc, định dạng và giới hạn nghiệp vụ cùng nhau.

Cũng hữu ích khi nhóm quy tắc theo đối tượng nghiệp vụ thay vì theo thiết bị. Một người dùng, đơn hàng, hóa đơn hoặc yêu cầu đăng ký nên có một bộ quy tắc áp dụng ở mọi nơi. Với mỗi đối tượng, ghi lại các trường, kiểm tra bắt buộc, quy tắc định dạng, ràng buộc nghiệp vụ và các mã lỗi mà backend trả về.

Điều này làm cho thay đổi an toàn hơn. Nếu doanh nghiệp quyết định số điện thoại là tùy chọn, bạn cập nhật một định nghĩa chia sẻ thay vì phải tìm khắp iPhone, Android, web và các màn hình quản trị.

Version hóa cũng quan trọng. Thay đổi quy tắc có thể làm vỡ các app cũ vẫn đang cài trên điện thoại khách hàng. Thay vì thay thế một quy tắc mà không để lại dấu vết, hãy version hóa thay đổi để backend có thể hỗ trợ các client cũ trong một thời gian ngắn khi các phiên bản mới được phát hành.

Một bước rà soát ngắn còn giúp hơn nhiều nhóm tưởng. Khi một quy tắc thay đổi, product có thể xác nhận mục tiêu nghiệp vụ và support cảnh báo những vấn đề thật sự của khách hàng, như trường tên từ chối dấu câu phổ biến hoặc quy tắc địa chỉ quá chặt.

Nếu bạn xây dựng với AppMaster, cách tiếp cận này phù hợp tự nhiên vì logic backend, web app và native mobile có thể quản lý trong một nền tảng no-code. Ý tưởng giống nhau áp dụng bất kỳ đâu: viết quy tắc một lần, giữ chúng ở chỗ trung tâm, và để mọi client tuân theo.

Kế hoạch triển khai đơn giản

Bạn không cần viết lại lớn để sửa lệch validation. Bắt đầu với một form và làm quy tắc rõ ràng.

Đầu tiên, liệt kê mọi trường và mô tả bằng ngôn ngữ đơn giản. Ghi rõ kiểu giá trị chấp nhận, có bắt buộc hay không, định dạng phải tuân theo, và điều kiện nghiệp vụ liên quan. "Email là bắt buộc" không đủ nếu một client chấp nhận định dạng sai và client khác chặn nó.

Sau đó thực hiện kiểm tra ở backend trước. Tiếp theo, phản chiếu các kiểm tra giống nhau trên web và mobile để người dùng nhận phản hồi nhanh trước khi gửi.

Một trình tự đơn giản hiệu quả:

1. Viết danh sách quy tắc từng trường một.
2. Đặt các quy tắc vào validation backend trước.
3. Thêm kiểm tra tương ứng trên frontend web.
4. Thêm cùng kiểm tra trên mobile.
5. Test cùng tập mẫu đầu vào ở mọi nơi.

Testing là nơi các khác biệt ẩn thường xuất hiện. Dùng một tập nhỏ ví dụ hợp lệ và không hợp lệ cho mỗi trường: giá trị rỗng, định dạng sai, giá trị ngay dưới giới hạn, đúng ở giới hạn, và ngay trên giới hạn. Nếu web và mobile đều khớp backend ở mọi trường hợp, bạn có hệ thống đáng tin cậy.

Ví dụ: form đăng ký khách hàng

Form đăng ký làm điều này dễ thấy. Giả sử form có ba trường: email, mật khẩu và ngày sinh.

Trên cả web lẫn mobile, form nên phản ứng cùng một cách trước khi người dùng gửi. Nếu email để trống, cả hai nên dừng và hiện cùng một thông báo. Nếu định dạng sai, cả hai nên bắt lỗi đó.

Quy tắc mật khẩu phải khớp chính xác. Nếu tối thiểu là 8 ký tự, thì phải là 8 ở mọi nơi, không phải 6 trên web và 10 trên mobile. Những khác biệt nhỏ thế này làm người dùng bối rối nhanh khi họ chuyển thiết bị.

Ngày sinh là nơi logic nghiệp vụ thường lệch. Nếu sản phẩm chỉ cho phép đăng ký từ 18 tuổi trở lên, cả hai client nên dùng cùng quy tắc cắt và cùng định nghĩa về "ngày hôm nay." Nếu không, một người dùng có thể được chấp nhận trên web và bị từ chối trong app.

Backend vẫn phải kiểm tra lại mọi thứ khi nhận yêu cầu. Ở đó bạn bắt được tài khoản trùng lặp, yêu cầu bị chỉnh sửa, và các phiên bản app cũ gửi dữ liệu lỗi thời.

Các thông điệp cũng nên rõ ràng và nhất quán. Ví dụ tốt: "Nhập địa chỉ email của bạn", "Nhập địa chỉ email hợp lệ", "Mật khẩu phải ít nhất 8 ký tự", và "Đã tồn tại tài khoản với email này." Khi người dùng thấy cùng ngôn ngữ ở mọi nơi, hỗ trợ dễ hơn và lòng tin tăng lên.

Những sai lầm khiến lệch xảy ra

Phần lớn vấn đề validation không đến từ một quy tắc rõ ràng bị hỏng. Chúng đến từ những khác biệt nhỏ tích tụ theo thời gian.

Một sai lầm phổ biến là ẩn quy tắc chỉ trong một client. App iPhone có thể yêu cầu số điện thoại trong khi web xem nó là tùy chọn. Sai lầm khác là dùng các mẫu khác nhau cho cùng một trường. Form web có thể cho phép dấu cách trong mã bưu chính trong khi app Android chặn, hoặc một client chấp nhận dấu cộng trong số điện thoại còn client khác loại bỏ nó.

Vấn đề nghiêm trọng hơn là quá tin vào UI. Validation phía client giúp người dùng sửa lỗi nhanh hơn, nhưng không bao giờ đủ. App cũ, trình duyệt lạ, và các yêu cầu trực tiếp tới API đều có thể gửi dữ liệu xấu nếu backend không thực thi cùng các ràng buộc nghiệp vụ.

Thông báo lỗi kém càng làm mọi thứ tệ hơn. "Dữ liệu không hợp lệ" không nói người dùng phải sửa gì. Một thông điệp rõ ràng thì có. Phiên bản app cũ là điều dễ bỏ sót: nếu bản phát hành mới thêm trường bắt buộc, các client cũ có thể tiếp tục gửi dữ liệu thiếu hàng tuần.

Khi validation liên tục bị lệch, nguyên nhân thường là đơn giản: trường bắt buộc ẩn, quy tắc định dạng khác nhau, kiểm tra backend yếu, thông báo lỗi mơ hồ, và không có kế hoạch cho các phiên bản cũ.

Kiểm tra phát hành bắt lỗi

Trước khi phát hành, hãy test cùng form theo cùng cách trên mọi client. Dùng một tập nhỏ các mẫu đầu vào và chạy chúng qua web app, mobile app, và API backend. Nếu một client chấp nhận giá trị mà client khác từ chối, quy tắc dùng chung của bạn chưa thực sự là chung.

Bắt đầu với các trường hợp cơ bản. Để trống các trường bắt buộc, nhập giá trị sai định dạng, và thử các trường hợp biên như ngày đúng giới hạn, tên chỉ một ký tự, hoặc trường đầy tới độ dài tối đa.

Kiểm tra trước phát hành của bạn nên trả lời một vài câu hỏi thẳng: web có từ chối cùng dữ liệu xấu như mobile không, backend có vẫn từ chối dữ liệu không hợp lệ ngay cả khi client bỏ sót không, và người dùng có thấy cùng ý nghĩa trong thông báo lỗi ở mọi nơi không?

Kiểm tra backend là quan trọng nhất. Nếu ai đó bỏ qua UI, dùng app cũ, hoặc gửi dữ liệu thẳng tới API, kết quả vẫn phải an toàn và có thể dự đoán được.

Cũng nên so sánh văn bản lỗi cạnh nhau. Nếu web nói "Nhập email hợp lệ" nhưng mobile nói "Lỗi không xác định", người ta sẽ cho rằng apps hành xử khác nhau dù cùng quy tắc.

Sau khi ra mắt, theo dõi phiếu hỗ trợ và phản hồi người dùng trong vài ngày. Các than phiền như "trên điện thoại được nhưng trên desktop không" thường chỉ ra khoảng trống validation nhanh hơn bất kỳ dashboard nào.

Bước tiếp theo rõ ràng hơn

Nếu form của bạn liên tục bị lỗi khác nhau trên web và mobile, đừng cố sửa mọi form cùng lúc. Bắt đầu với form gây nhiều vấn đề lặp lại nhất, thường là đăng ký, thanh toán, hoặc chỉnh sửa hồ sơ.

Di chuyển các quy tắc chặt chẽ vào logic backend trước. Điều đó bao gồm trường bắt buộc, kiểm tra định dạng, kiểm tra trùng lặp và giới hạn nghiệp vụ như tuổi, loại tài khoản hoặc vùng. Sau đó để web và mobile phản chiếu các kiểm tra đó để người dùng nhận phản hồi nhanh và rõ ràng.

Viết quy tắc bằng ngôn ngữ đơn giản. Thay vì "validate customer status," hãy viết "Khách hàng doanh nghiệp phải nhập mã số thuế" hoặc "Số điện thoại là tùy chọn trừ khi bật thông báo SMS." Cách diễn đạt rõ ràng giúp designer, developer, tester và support dễ phát hiện lỗ hổng trước khi phát hành.

Nếu muốn giảm công việc lặp lại, AppMaster có thể giúp vì nó cho phép các nhóm xây backend, web và native mobile từ một hệ thống. Điều đó giúp giữ logic nghiệp vụ đồng bộ trong khi vẫn cung cấp phản hồi nhanh trên từng client.

Mục tiêu không phải là hoàn hảo mọi form ngay lập tức. Mục tiêu là ít bất ngờ hơn, ít phiếu hỗ trợ hơn, và validation web-mobile giữ nhất quán khi sản phẩm phát triển.