Công cụ dành cho nhà phát triển · Trình tạo UUID
Khóa tạm thời: Sử dụng UUID do khách hàng tạo để đảm bảo an toàn cho lần thử lại
· Tại sao nó quan trọng
uuid mật mã browser-apis
Yêu cầu thanh toán hết thời gian chờ khiến bạn không chắc liệu yêu cầu đó có được thực hiện hay không. Khóa tạm thời cho phép bạn thử lại một cách an toàn và CSPRNG được tạo UUID là khóa tự nhiên. Bài đăng này giải thích mô hình từ đầu đến cuối.
Thời gian chờ có thể đã khiến khách hàng bị tính phí hai lần — tồn tại các khóa tạm thời của chế độ lỗi để khắc phục
Thời gian chờ trong khi yêu cầu thanh toán tạo ra sự không chắc chắn thực sự cho khách hàng và hệ thống. Khách hàng HTTP của bạn đã không chờ phản hồi nhưng máy chủ thanh toán có thể đã xử lý giao dịch trước khi kết nối bị đóng hoặc hết thời gian chờ. Nếu bạn thử lại cùng một yêu cầu, bạn có thể tính phí khách hàng hai lần. Nếu bạn không thử lại, việc thanh toán sẽ không bao giờ hoàn tất. Hệ thống thanh toán gặp trục trặc ở một điểm trung gian không vui: tiền của khách hàng có thể đã hết, có thể đến vào ngày mai, có thể bị kẹt trong hàng đợi xử lý hoặc có thể chưa rời khỏi tài khoản. Sự mơ hồ này là không thể chấp nhận được đối với các hệ thống tài chính.
Cách hoạt động của khóa tạm thời - máy chủ lưu trữ phản hồi đầu tiên dưới khóa và phát lại nó để lặp lại
Khóa tạm thời giải quyết vấn đề này một cách khéo léo bằng cách làm cho việc thử lại trở nên an toàn và mang tính quyết định. Khách hàng tạo một khóa duy nhất cho mỗi mục đích—thanh toán, chuyển khoản, tính phí—và đưa khóa đó vào mọi yêu cầu. Máy chủ xử lý thanh toán, lưu trữ phản hồi theo khóa đó và lưu trữ cả khóa và kết quả. Nếu cùng một khóa đó xuất hiện trở lại trong cửa sổ lưu giữ, máy chủ sẽ phát lại phản hồi được lưu trong bộ nhớ đệm mà không xử lý lại khoản thanh toán. Khách hàng có thể tự tin thử lại khi biết rằng cùng một khóa sẽ luôn mang lại kết quả tương tự, bất kể nó được gửi bao nhiêu lần. Mẫu này giúp loại bỏ sự mơ hồ và làm cho logic thử lại trở nên an toàn.
Tạo trước lần thử đầu tiên - tại sao khóa phải tồn tại trước khi yêu cầu rời đi và được sử dụng lại nguyên văn khi thử lại
Mẫu này cũ hơn các thông số kỹ thuật HTTP hiện đại nhưng đã trở nên nổi bật trong thanh toán sau những tổn thất tài chính lan rộng và khiếu nại của khách hàng về các khoản phí trùng lặp. Mọi khoản thanh toán API và nhiều API dịch vụ web hiện đều hỗ trợ khóa tạm thời. CSPRNG được tạo UUID là lựa chọn đương nhiên cho khóa vì nó không thể đoán được, duy nhất mà không có bất kỳ sự phối hợp nào giữa các máy khách và không yêu cầu phân bổ phía máy chủ hoặc cơ quan trung ương. Máy khách tạo nó trước lần thử đầu tiên, sử dụng lại nguyên văn trong mỗi lần thử lại và nhận được phản hồi giống nhau mỗi lần. Không cần trạng thái phía máy chủ để điều phối việc tạo khóa.
Tại sao lại là UUID ngẫu nhiên mà không phải là hàm băm bộ đếm hoặc tải trọng — tính duy nhất mà không cần phối hợp và không vô tình tái sử dụng trong các ý định
Khóa phải tồn tại trước khi yêu cầu rời khỏi máy khách vì việc tạo nó khi thử lại đã quá muộn để đảm bảo tính tạm thời. Nếu yêu cầu đầu tiên thành công và tính phí cho khách hàng, việc tạo khóa mới khi thử lại sẽ che giấu vấn đề và tính phí lại. Máy khách phải cam kết một khóa trước lần thử đầu tiên, lưu nó vào bộ nhớ hoặc bộ lưu trữ liên tục và sử dụng lại khóa đó nếu cần phải hết thời gian chờ hoặc thử lại. Đối với thử nghiệm API thủ công, trình tạo ToolAcre tạo ra các khóa mà bạn có thể dán vào ứng dụng khách cuộn tròn hoặc ứng dụng khách REST, sao chép và sử dụng lại trên nhiều yêu cầu để kiểm tra hành vi bình thường.
Phạm vi và thời gian tồn tại - các khóa cho mỗi hoạt động, mỗi tài khoản và thời gian máy chủ ghi nhớ chúng
Tại sao lại là UUID thay vì bộ đếm băm hoặc bộ đếm tuần tự cho các khóa bình thường? Hàm băm của tải trọng yêu cầu có vẻ trực quan—các tải trọng giống hệt nhau sẽ nhận được các giá trị băm giống hệt nhau và do đó các khóa giống hệt nhau. Tuy nhiên, hàm băm yếu trong trường hợp sử dụng này vì hai yêu cầu gần như giống hệt nhau với số lượng khác nhau, người nhận khác nhau hoặc thông số khác nhau tạo ra các hàm băm hoàn toàn khác nhau và do đó tạo ra các khoản phí riêng biệt, điều này đúng nhưng không cung cấp tất cả sự bảo vệ cần thiết. Bộ đếm tuần tự yêu cầu trạng thái phối hợp và phân tán: nếu cả hai máy khách đều tạo khóa dựa trên bộ đếm trên cơ sở hạ tầng của bạn thì bộ đếm của họ có thể xung đột. UUID không yêu cầu cơ quan trung ương nào, không thể đoán được và cực kỳ khó xảy ra va chạm ngẫu nhiên trên toàn bộ Internet trong mọi thời điểm.
Ví dụ đã hoạt động - một chuỗi thử lại có cùng khóa, hiển thị những gì khách hàng gửi và những gì máy chủ trả về mỗi lần
Việc triển khai phía máy chủ lưu trữ các phản hồi dưới các khóa và trả về các phản hồi được lưu trong bộ nhớ đệm khi lặp lại. Sự phức tạp nằm ở việc quyết định các câu hỏi vận hành thực tế: thời gian lưu giữ để nhớ một khóa trong bao lâu, kích thước bộ đệm cần nhớ bao nhiêu khóa, khóa cách ngăn hai yêu cầu đồng thời có cùng một khóa xử lý thanh toán hai lần và dọn dẹp khi nào quên chìa khóa. Đây là các câu hỏi về độ tin cậy và lưu trữ nằm ngoài phạm vi của trình tạo UUID. Công việc của khách hàng là tạo một khóa tốt và sử dụng lại nó khi thử lại; công việc của máy chủ là triển khai bộ đệm một cách chính xác và lâu dài.
Điều này không bao gồm - việc lưu trữ và khóa phía máy chủ cần thiết để triển khai mẫu, đây là một thiết kế riêng biệt
Một ví dụ hoạt động cho thấy một trình tự điển hình trong thực tế. Ứng dụng dành cho thiết bị di động cần chuyển tiền cho bạn bè bằng cách sử dụng API hỗ trợ tính tạm thời. Trước khi gửi yêu cầu, ứng dụng sẽ tạo UUID bằng cách sử dụng thư viện mật mã cục bộ hoặc tìm nạp một yêu cầu từ trình tạo ToolAcre cho mục đích thử nghiệm: 3fa85f64-5717-4562-b3fc-2c963f66afa6. Ứng dụng gửi yêu cầu POST tới /transfers với nội dung JSON và tiêu đề HTTP Idempotency-Key: 3fa85f64-5717-4562-b3fc-2c963f66afa6. Máy chủ xử lý quá trình truyền, lưu trữ 3fa85f64-5717-4562-b3fc-2c963f66afa6 → {status: "success", transferId: "xfer-12345"} trong bộ đệm và trả về phản hồi 200 cùng với kết quả.
Bài học rút ra: một ý định, một khóa — trình tạo ToolAcre cung cấp cho bạn CSPRNG được hỗ trợ UUID để sử dụng làm khóa khi kiểm tra tích hợp bằng tay
Mạng hết thời gian chờ và máy khách không thấy phản hồi từ lần thử đầu tiên. Ứng dụng thử lại cùng một yêu cầu với cùng một khóa tạm thời mà không tạo UUID mới. Máy chủ nhận ra khóa trong bộ nhớ đệm, tìm phản hồi được lưu trong bộ nhớ đệm và ngay lập tức trả về {status: "success", transferId: "xfer-12345"} mà không cần xử lý giao dịch truyền mới cũng như không tính phí khách hàng lần nữa. Hoạt động này bình thường: việc thử lại sẽ tạo ra kết quả có thể quan sát được ở mọi lần. Để kiểm tra thành công, trình tạo ToolAcre có thể cung cấp khóa; tạo UUID, đưa nó vào tiêu đề, quan sát phản hồi và gửi lại bằng cùng một khóa để xác minh máy chủ triển khai bộ đệm ẩn chính xác.