Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Wprowadzenie
Kody paskowe wyglądają jak zwykłe kody kreskowe, ale zmieniają się okresowo
zwykle co minutę, a terminal/czytnik jest tak zaprogramowany, aby
najnowszego. To zabezpieczenie zmniejsza ryzyko związane z
robienie zrzutów ekranu z kodem kreskowym, w szczególności kradzież biletu lub nieautoryzowany bilet
sprzedaż. Funkcja rotacji kodów kreskowych może też działać jako kod zastępczy w przypadku urządzeń, które nie mogą
korzystają z technologii smart tap ze względu na brak obsługi NFC (brak sprzętu lub
wyłączone oprogramowanie).
Dokumentacja API
Szczegółowe informacje techniczne dotyczące rotacji kodów kreskowych znajdziesz w dokumentacji
Typ RotatingBarcode.
Na urządzeniu użytkownika w danym momencie używany jest tylko jeden mechanizm wykorzystania karty.
w zależności od konfiguracji karty i możliwości urządzenia.
Używane są te typy promocji (w kolejności według priorytetu):
Smart Tap: jeśli określono ładunek smart tap, a urządzenie obsługuje
NFC/HCE
Pamiętaj, że użytkownik może to zmienić, klikając „Pokaż kod”, co
wymusza wyświetlanie obracającego się kodu kreskowego/statycznego kodu kreskowego.
Rotacja kodu kreskowego: jeśli określono rotację kodu kreskowego
Statyczny kod kreskowy: jeśli określono ładunek kodu kreskowego
Podanie wielu ładunków wykorzystania może zapewnić, że wszyscy użytkownicy będą obsługiwani, ale
może mieć wpływ na bezpieczeństwo. Przede wszystkim użycie statycznego kodu kreskowego jako
rotacja kodu kreskowego eliminuje większość korzyści zapewnianych przez
obracających się kodów kreskowych. Statyczny kod kreskowy będzie wyświetlany tylko w widokach internetowych
lub w przypadku klientów, którzy nie obsługują rotacji kodów kreskowych. Od dzisiaj
wszystkich klientów Portfela Google z obsługą rotacji kodów kreskowych.
Zapisz proces
Interfejs API Portfela Google oferuje kilka procesów, w tym:
tworzenie zajęć dotyczących transportu publicznego w czasie rzeczywistym lub z wyprzedzeniem;
Przesłanie pełnych obiektów w tokenie JWT lub zapisanie ich przed
czas, a następnie odwołuj się do nich za pomocą identyfikatora w JWT
aktualizowanie obiektów po ich zapisaniu;
Proponowane pole rotacji kodu kreskowego jest zgodne ze wszystkimi tymi przepływami.
jednak w celu poprawy bezpieczeństwa sugerujemy wykonanie tych czynności:
Wywołaj interfejs API object:insert, aby wstawić kartę do
serwera Portfela Google i skonfigurować przycisk Dodaj do Portfela Google, aby
odwołują się do konkretnego obiektu za pomocą identyfikatora w tokenie JWT. Dzięki temu
powstały w ten sposób token JWT nie zawiera tajnego klucza rotacji kodu kreskowego.
Użyj klucza obiektu tajnego dla hasła jednorazowego z zakresu pojedynczej karty
Jeśli klucz nie zostanie zaktualizowany, powinien być ważny przez okres ważności
karnetu. Nie spodziewamy się, aby ten klucz był aktualizowany w żadnej częstotliwości
w trakcie normalnego działania.
Poniższy diagram przedstawia przepływ między różnymi podmiotami
w przypadku typowej integracji:
[null,null,["Ostatnia aktualizacja: 2025-08-29 UTC."],[[["\u003cp\u003eRotating barcodes enhance security by changing periodically, mitigating risks associated with ticket theft or unauthorized resale.\u003c/p\u003e\n"],["\u003cp\u003eThey serve as a fallback for devices lacking NFC support, ensuring accessibility for all users.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Wallet prioritizes Smart Tap, followed by rotating barcodes, and lastly static barcodes for pass redemption.\u003c/p\u003e\n"],["\u003cp\u003eFor optimal security, it is recommended to save pass objects to the Google Wallet server and reference them by ID in JWTs, avoiding exposure of the rotating barcode's secret key.\u003c/p\u003e\n"],["\u003cp\u003eEach pass should ideally have a unique OTP secret key, remaining valid throughout the pass's lifespan.\u003c/p\u003e\n"]]],["Rotating barcodes change periodically, enhancing security against screenshotting and ticket theft. They serve as a fallback for devices lacking NFC capabilities. The system prioritizes Smart Tap, then rotating barcodes, and lastly static barcodes for redemption. Using static barcodes alongside rotating ones compromises security. The API supports various saving flows, recommending using the `object:insert` API to avoid including the barcode's secret key in the JWT, using an OTP secret key and expecting the key to be valid for the life span of the pass.\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/tickets/transit-passes/qr-code/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 transit 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:"]]
