با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
مقدمه
بارکدهای چرخان مانند بارکدهای معمولی به نظر می رسند، اما به طور دوره ای، معمولاً هر دقیقه تغییر می کنند، و ترمینال/خواننده طوری برنامه ریزی شده است که فقط جدیدترین را بپذیرد. این اقدام امنیتی خطرات مربوط به اسکرین شات گرفتن بارکد، به ویژه سرقت بلیط یا فروش مجدد غیرمجاز بلیط را کاهش می دهد. بارکدهای چرخان همچنین می توانند به عنوان بازگشتی برای دستگاه هایی عمل کنند که به دلیل پشتیبانی نکردن از NFC (عدم سخت افزار یا نرم افزار غیرفعال) نمی توانند از مزیت Smart Tap استفاده کنند.
در دستگاه کاربر، بسته به نحوه پیکربندی پاس و قابلیت‌های دستگاه، تنها از یک مکانیسم بازخرید در یک زمان معین استفاده می‌شود. به ترتیب اولویت، از انواع بازخرید زیر استفاده می شود:
Smart Tap: اگر یک محموله ضربه ای هوشمند مشخص شده باشد و اگر دستگاه از NFC/HCE پشتیبانی می کند
توجه داشته باشید، کاربر می تواند با کلیک کردن روی "نمایش کد" این مورد را لغو کند، که نمایش بارکد در حال چرخش / بارکد ثابت را مجبور می کند.
بارکد چرخشی: اگر بار بارکد چرخشی مشخص شده باشد
بارکد استاتیک: اگر بار کد بارکد مشخص شده باشد
تعیین بارهای بازخرید چندگانه می تواند اطمینان حاصل کند که همه کاربران پشتیبانی می شوند اما ممکن است پیامدهای امنیتی داشته باشد. به طور خاص، استفاده از یک بارکد ثابت به عنوان جایگزین برای بارکد چرخان، بسیاری از مزایای امنیتی استفاده از بارکدهای چرخان را نفی می کند. بازگشتی بارکد ثابت فقط در نماهای وب یا در کلاینت هایی نشان داده می شود که از بارکدهای چرخشی پشتیبانی نمی کنند. از امروز، انتظار داریم همه مشتریان Google Wallet از بارکدهای چرخشی پشتیبانی کنند.
ذخیره جریان
Google Wallet API چندین جریان را ارائه می دهد، از جمله:
ایجاد کلاس های عمومی در زمان صرفه جویی یا زودتر از موعد
ارسال اشیاء کامل در JWT یا ذخیره اشیاء قبل از زمان و سپس ارجاع آنها با شناسه در JWT شما
به روز رسانی اشیاء پس از ذخیره شدن
فیلد بارکد چرخشی پیشنهادی با تمام این جریان‌ها سازگار است، اما به منظور بهبود امنیت، موارد زیر را پیشنهاد می‌کنیم:
برای درج پاس به سرور Google Wallet object:insert API را فراخوانی کنید و دکمه Add to Google Wallet را برای ارجاع به شی خاص با شناسه در JWT خود پیکربندی کنید. این تضمین می کند که JWT حاصل کلید مخفی بارکد چرخان را شامل نمی شود.
از یک کلید مخفی OTP استفاده کنید که به یک پاس اختصاص داده شده است
انتظار می رود که کلید، مگر اینکه به روز شود، برای طول عمر پاس معتبر باشد. ما انتظار نداریم که این کلید در هیچ فرکانسی در طول کارکرد عادی به روز شود.
نمودار توالی زیر جریان بین بازیگران مختلف را برای یک ادغام معمولی نشان می دهد:
تاریخ آخرین بهروزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی."],[[["\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:"]]
