رموز شريطية دوّارة

مقدمة

إنّ الرموز الشريطية الدوّارة تشبه تمامًا الرموز الشريطية العادية، ولكنّها تتغيّر بشكل دوري كل دقيقة في العادة، وتتم برمجة محطة الدفع/القارئ لقبول العرض الأحدث فقط. يحدّ هذا الإجراء الأمني من المخاطر المرتبطة بأخذ لقطات الشاشة الشريطية، لا سيّما سرقة التذاكر أو إعادة بيع التذاكر غير المصرّح بها. يمكن أن تكون الرموز الشريطية الدوّارة أيضًا بمثابة عنصر احتياطي للأجهزة التي لا يمكنها الاستفادة من ميزة "الدفع الذكي" بسبب عدم توافقها مع تقنية NFC (نقص الأجهزة أو البرامج غير مفعَّلة).

مرجع واجهة برمجة التطبيقات

لمعرفة التفاصيل الفنية حول الرموز الشريطية الدوّارة، يُرجى الاطّلاع على النوع RotatingBarcode.

مثال على الحمولة

JSON 
{
  "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"
        }
      ]
    }
  }
}

الآليات الاحتياطية

على جهاز المستخدم، يتم استخدام آلية واحدة فقط لتحصيل القيمة في وقت معيّن، وذلك استنادًا إلى كيفية ضبط البطاقة وعلى إمكانات الجهاز. يتمّ استخدام أنواع تحصيل القيمة التالية بترتيب الأولوية:

  1. الدفع الذكي: إذا تم تحديد حمولة البيانات الناتجة عن النقر الذكي وإذا كان الجهاز متوافقًا مع تقنية NFC أو HCE
    • ملاحظة: يمكن للمستخدم إلغاء هذا الإجراء من خلال النقر على "عرض الرمز"، ما سيؤدي إلى فرض عرض الرمز الشريطي الدوّار/الرمز الشريطي الثابت.
  2. رمز شريطي دوّار: في حال تحديد حمولة بيانات شريطية دوّارة
  3. رمز شريطي ثابت: في حال تحديد حمولة بيانات شريطية

يمكن أن يؤدي تحديد عدة أحمال لتحصيل القيمة إلى ضمان توفير الدعم لجميع المستخدمين، ولكن قد تترتّب على ذلك آثار أمنية. وعلى وجه الخصوص، يؤدي استخدام رمز شريطي ثابت كبديل لرمز شريطي دوّار إلى إلغاء معظم مزايا الأمان لاستخدام الرموز الشريطية الدوّارة. لن يظهر عنصر احتياطي للرمز الشريطي الثابت إلا في صفحات الويب أو على البرامج التي لا تتيح استخدام الرموز الشريطية الدوّارة. واعتبارًا من اليوم، نتوقّع أن يتيح جميع عملاء "محفظة Google" استخدام الرموز الشريطية المتغيّرة.

حفظ التدفق

تقدّم Google Wallet API عدة مسارات، بما في ذلك:

  • إنشاء فصول العروض في وقت توفيره أو في وقت مبكر
  • إرسال العناصر بالكامل في JWT أو حفظها مسبقًا ثم الإشارة إليها باستخدام رقم التعريف في JWT
  • تعديل العناصر بعد حفظها

يتوافق حقل rotatingBarcode (الرمز الدوراني) المقترَح مع جميع هذه التدفقات، ومع ذلك، لتحسين مستوى الأمان، نقترح ما يلي:

  • يمكنك طلب واجهة برمجة التطبيقات object:insert لإدراج البطاقة في خادم "محفظة Google" وضبط الزر "إضافة إلى محفظة Google" للإشارة إلى العنصر المحدّد من خلال رقم التعريف في مستند JWT. ويضمن ذلك عدم احتواء رمز JWT الناتج على المفتاح السري للرمز الشريطي الدوّار.
  • يجب استخدام مفتاح سري خاص بكلمة المرور لمرة واحدة (OTP) يستند إلى بطاقة واحدة.
  • من المتوقّع أن يكون المفتاح صالحًا لمدة البطاقة، ما لم يتم تعديله. ولا نتوقّع تعديل هذا المفتاح بأي معدّل تكرار خلال التشغيل العادي.

يوضِّح مخطّط التسلسل التالي التدفق بين الجهات الفاعلة المختلفة في عملية دمج نموذجية:

مخطّط تسلسلي لاستخدام الرموز الشريطية الدوّارة