Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Giới thiệu
Mã vạch xoay trông giống như mã vạch thông thường nhưng thay đổi định kỳ,
thường mỗi phút và thiết bị đầu cuối/đầu đọc được lập trình để chỉ chấp nhận
email gần đây nhất. Biện pháp bảo mật này giúp giảm rủi ro liên quan đến
ảnh chụp màn hình mã vạch, cụ thể là hành vi trộm cắp vé hoặc vé trái phép
bán lại. Việc xoay mã vạch cũng có thể đóng vai trò là phương án dự phòng cho các thiết bị không thể
tận dụng công nghệ Chạm thông minh do không hỗ trợ NFC (thiếu phần cứng, hoặc
phần mềm bị tắt).
Trên thiết bị của người dùng, chỉ một cơ chế đổi thưởng được sử dụng tại một thời điểm nhất định,
tuỳ thuộc vào cách định cấu hình thẻ và vé cũng như khả năng của thiết bị.
Các loại đổi thưởng sau đây được sử dụng theo thứ tự ưu tiên:
Chạm thông minh: Nếu có chỉ định tải trọng của thao tác nhấn thông minh và thiết bị có hỗ trợ
NFC/HCE
Lưu ý rằng người dùng có thể ghi đè giá trị này bằng cách nhấp vào "Hiển thị mã".
sẽ buộc hiển thị mã vạch/mã vạch tĩnh đang xoay.
Mã vạch xoay: Nếu tải trọng mã vạch xoay được chỉ định
Mã vạch tĩnh: Nếu tải trọng mã vạch được chỉ định
Việc chỉ định nhiều tải trọng đổi thưởng có thể đảm bảo tất cả người dùng đều được hỗ trợ nhưng
có thể ảnh hưởng đến tính bảo mật. Cụ thể, việc sử dụng mã vạch tĩnh làm
dự phòng cho mã vạch xoay phủ định hầu hết các lợi ích bảo mật khi sử dụng
xoay vòng mã vạch. Mã vạch dự phòng tĩnh sẽ chỉ xuất hiện trong các chế độ xem trên web
hoặc trên các ứng dụng không hỗ trợ mã vạch xoay. Kể từ hôm nay, chúng tôi dự kiến
tất cả ứng dụng khách Google Wallet hỗ trợ mã vạch xoay.
Lưu quy trình
API Google Wallet cung cấp một số quy trình, bao gồm:
Tạo các lớp chung mà không cần tiết kiệm thời gian hoặc tạo trước thời hạn
Gửi các đối tượng hoàn chỉnh trong JWT hoặc lưu các đối tượng trước
sau đó tham chiếu chúng theo mã nhận dạng trong JWT của bạn
Cập nhật đối tượng sau khi lưu
Trường Mã vạch xoay được đề xuất tương thích với tất cả các quy trình này,
tuy nhiên, để tăng cường tính bảo mật, bạn nên làm như sau:
Gọi API object:insert để chèn thẻ/vé vào
Máy chủ Google Wallet và định cấu hình nút Thêm vào Google Wallet để
tham chiếu đối tượng cụ thể theo mã nhận dạng trong JWT của bạn. Điều này đảm bảo rằng
kết quả JWT không bao gồm khoá bí mật của mã vạch xoay.
Sử dụng khoá bí mật OTP trong phạm vi một lượt truyền
Trừ phi được cập nhật, khoá này sẽ có hiệu lực trong vòng đời
thẻ/vé. Chúng tôi dự kiến sẽ không cập nhật khoá này theo tần suất bất kỳ trong
quá trình hoạt động bình thường.
Sơ đồ trình tự dưới đây minh hoạ luồng giữa các tác nhân khác nhau
cho một tích hợp thông thường:
[null,null,["Cập nhật lần gần đây nhất: 2025-08-29 UTC."],[[["\u003cp\u003eRotating barcodes enhance security by changing periodically, mitigating risks like ticket theft and unauthorized resale, serving as an alternative to Smart Tap for devices lacking NFC capabilities.\u003c/p\u003e\n"],["\u003cp\u003eDevices prioritize redemption methods in the order of Smart Tap, Rotating Barcode, and then Static Barcode, with users having the option to override Smart Tap and display the barcode.\u003c/p\u003e\n"],["\u003cp\u003eFor optimal security, it's recommended to utilize the \u003ccode\u003eobject:insert\u003c/code\u003e API for pass creation, employ pass-specific OTP secret keys, and acknowledge that these keys are typically valid for the pass's lifespan.\u003c/p\u003e\n"],["\u003cp\u003eRotating barcodes function by encoding a time-based one-time password (TOTP) within the barcode, requiring the scanning device to validate it against the current time, thereby ensuring only the latest barcode is accepted.\u003c/p\u003e\n"]]],["Rotating barcodes, which change periodically (e.g., every minute), enhance security by preventing screenshot misuse and ticket theft. They serve as a fallback for devices lacking NFC capabilities. The API uses a `RotatingBarcode` type with details like algorithm, period, and parameters. Redemption mechanisms prioritize Smart Tap, then rotating barcodes, and lastly, static barcodes. For security, it's recommended to use the `object:insert` API and an OTP secret key unique to each pass and avoid using static barcodes as fallback.\n"],null,["# Rotating Barcodes\n\nIntroduction\n------------\n\n\nRotating barcodes look just like regular barcodes but change periodically,\ntypically every minute, and the terminal/reader is programmed to only accept\nthe most recent one. This security measure reduces the risks associated with\nbarcode screenshotting, in particular ticket theft or unauthorized ticket\nresale. Rotating barcodes can also act as a fallback for devices that can't\ntake advantage of Smart Tap, due to not supporting NFC (lack of hardware, or\nsoftware disabled).\n\n### API reference\n\n\nFor technical details about Rotating Barcodes, see the\n[`RotatingBarcode` type](/wallet/generic/rest/v1/RotatingBarcode).\n\n### Example payload\n\n| JSON ||\n|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---|\n| ``` { \"rotatingBarcode\": { \"type\": \"QR_CODE\", \"valuePattern\": \"MyRotatingBarcode-{totp_timestamp_seconds}-{totp_value_0}\", \"alternateText\": \"Ticket#: 1234567890\", \"totpDetails\": { \"algorithm\": \"TOTP_SHA1\", \"periodMillis\": \"3000\", \"parameters\": [ { \"key\": \"3132333435363738393031323334353637383930\", \"valueLength\": \"8\" } ] } } } ``` |\n\nFallback Mechanisms\n-------------------\n\n\nOn the user device, only one redemption mechanism is used at a given time,\ndepending on how the pass is configured and on the capabilities of the device.\nIn the order of priority, the following redemption types are used:\n\n1. Smart Tap: If a smart-tap payload is specified and if the device supports NFC/HCE\n - Note, this can be overridden by the user by clicking \"Show code,\" which will force the display of the rotating barcode/static barcode.\n2. Rotating barcode: If a rotating barcode payload is specified\n3. Static barcode: If a barcode payload is specified\n\n\nSpecifying multiple redemption payloads can ensure all users are supported but\nmay have security implications. In particular, using a static barcode as a\nfallback for a rotating barcode negates most of the security benefits of using\nrotating barcodes. A static barcode fallback will only be shown in web views\nor on clients that do not support rotating barcodes. As of today, we expect\nall Google Wallet clients to support rotating barcodes.\n\nSave Flow\n---------\n\nThe Google Wallet API offers several flows, including:\n\n- Creating the generic classes at save time, or ahead of time\n- Sending the complete objects in your JWT, or saving the objects ahead of time then referencing them by ID in your JWT\n- Updating the objects after they have been saved\n\n\nThe proposed rotatingBarcode field is compatible with all these flows,\nhowever, in order to improve security, we suggest the following:\n\n- Call the `object:insert` API to insert the pass to the Google Wallet server and configure the Add to Google Wallet button to reference the specific object by ID in your JWT. This ensures that the resulting JWT does not include the secret key of the rotating barcode.\n- Use an OTP secret key that is scoped to a single pass\n- The key, unless it is updated, is expected to be valid for the lifespan of the pass. We do not expect this key to be updated on any frequency during the course of normal operation.\n\n\nThe following sequence diagram illustrates the flow between the various actors\nfor a typical integration:"]]