مهلة رموز Shopify في 2027: أي التطبيقات يجب تحديثها؟

آخر مراجعة: 3 نوفمبر 2026. إذا كنت تطور تطبيق Shopify عامًا يستخدم رموز وصول غير منتهية الصلاحية (non-expiring offline access tokens) للاتصال بـAdmin API، فعليك تجهيز الانتقال قبل 1 يناير 2027. هذا لا يعني أن كل متجر Shopify أو قالب أو تطبيق مخصص يحتاج إلى تعديل. في إعلان 27 أكتوبر، وضعت Shopify مراحل للتطبيقات العامة القديمة غير الممتثلة: إيقاف ظهورها وتثبيتها الجديد في المتجر يوم 1 يناير، وتحذير التجار في 15 يناير، ثم رفض طلبات Admin API المعنية برمز HTTP 403 بدءًا من 1 أبريل. الإعلان الرسمي المؤرخ.

هذا دليل قرار لفريق تطوير التطبيقات وأصحاب الشركات الذين يعتمدون عليها، مع قائمة فحص عملية. الجداول من إعداد تحريري وليست نتيجة اختبار أجراه فريق NxFold على تطبيق عميل أو حساب Shopify حقيقي.

هل تطبيقك مشمول أصلًا؟#

هذه الحدود موضحة في تحديث 27 أكتوبر ومرجع رموز الوصول. صاحب المتجر يسأل مزود التطبيق عن جاهزيته؛ لا يضيف كود OAuth إلى القالب.

المواعيد الثلاثة، واختلاف مهم بين وثائق Shopify#

تحديث المواعيد بعد التحقق في 3 نوفمبر 2026: تتفق الآن نشرة Shopify بتاريخ 27 أكتوبر وتوضيح فريق Shopify في 30 أكتوبر ودليل الترحيل الحالي على المراحل التالية: 1 يناير لإزالة التطبيقات غير الممتثلة ومنع تثبيتها الجديد، و15 يناير لتحذيرات التجار، و1 أبريل لرفض طلبات API المتأثرة بالرموز القديمة. استخدمت نسخ سابقة من بعض الوثائق موعدا مختلفا للرفض، لكن هذا التعارض لم يعد موجودا في دليل الترحيل الحالي. يشمل توضيح الفريق استخدام GraphQL وREST Admin API، بينما يركز دليل الترحيل على GraphQL؛ راجع الاتصالات الحقيقية في تطبيقك. قد يستمر التنبيه بسبب استخدام رمز قديم خلال آخر 14 يوما، لذا افحص المهام الخلفية والطوابير المؤجلة. اكمل الترحيل واختباره قبل 1 يناير ولا تعتبر فترة السماح مهلة اضافية. هذه مواعيد رسمية وليست نتيجة اختبار نفذته NxFold.

ما الفرق بين الرمز الدائم والرمز المنتهي؟#

يحتاج التطبيق أحيانًا إلى العمل دون وجود موظف داخل لوحة Shopify، مثل مهام مزامنة الطلبات أو معالجة webhooks. لهذا يُستخدم offline access token. الرمز الدائم يبقى صالحًا حتى إلغائه أو إزالة التطبيق. أما الرمز المنتهي فتكون له مدة محددة ويأتي معه refresh token للتجديد. توثق Shopify حاليًا مدة تقارب ساعة واحدة لرمز الوصول و90 يومًا لرمز التجديد عند إصداره، لكن يجب اعتماد حقول الاستجابة الفعلية expires_in وrefresh_token_expires_in بدل تثبيت الأرقام في الكود. مرجع رموز Shopify.

عند التجديد تتغير نسخة رمز الوصول ورمز التجديد معًا. احفظهما مع بيانات انتهاء الصلاحية في عملية تخزين متماسكة ومحمية ومفصولة لكل متجر. لا تسمح لعامِلَين بتجديد رمز المتجر ذاته في اللحظة نفسها. توضح Shopify أن تحسين آلية الاستعادة في 28 أغسطس قد يساعد عند ضياع الاستجابة، لكنه ليس مبررًا للاعتماد الدائم على الرمز القديم.

اختر مسار الترحيل حسب بناء التطبيق#

تطبيق مبني على قالب React Router أو Remix الرسمي: تحقق من إصدار المكتبات وتوافق قاعدة بيانات الجلسات. تذكر Shopify تفعيل future: { expiringOfflineAccessTokens: true } داخل shopifyApp()، وتوضح أن القالب يتعامل مع التخزين والتجديد اللاحق. لكن تفعيل الخيار وحده لا يثبت انتقال كل التثبيتات القديمة. دليل القوالب.

تطبيق ينفذ token exchange بنفسه: أضف expiring=1 إلى طلب الحصول على الرمز وفق تدفق المصادقة الموثق. احفظ access_token وrefresh_token وexpires_in وrefresh_token_expires_in بصورة آمنة. اجعل تجديد الرموز منظّمًا لكل متجر، ولا تطبع القيم الحساسة في السجلات.

تطبيق يستخدم OAuth authorization code: توثق Shopify خيار expiring=1 عند استبدال رمز التفويض برمز وصول. تحقق من وجود آلية تجديد لكل تثبيت، ومسار لاستعادة الدخول عند فشل الرمز.

متاجر لا تفتح التطبيق أو مهام خلفية فقط: الانتظار حتى يدخل التاجر للتطبيق قد يترك تثبيتات قديمة. لذلك توفر Shopify تبادل ترحيل مباشر يستخدم رمز offline الدائم القديم النشط وبيانات التطبيق، دون جلسة مستخدم. هذا التبادل يلغي صلاحية الرمز القديم لاستخدام GraphQL Admin API؛ فلا تبدأ نقل مجموعة كبيرة قبل اختبار التخزين والاستعادة. الاستعادة بعد ضياع الرد مشروطة وليست تصريحًا بإعادة كل طلب مصادقة بشكل عشوائي. إجراء الترحيل الرسمي.

أعلنت Shopify أيضًا خيار client credentials لبعض الحالات المؤهلة، باستخدام توقيع بمفتاح خاص للحصول على رمز مؤقت من الخادم. هذا خيار إضافي للاستعادة، وليس دليلًا على أن تطبيقك أكمل الترحيل. تحديث الأمان.

جدول الاختبار قبل الانتقال للإنتاج#

استخدم متجر اختبار مصرحًا به وسجلات منزوعة البيانات الحساسة. سجّل نجح / فشل / لم يُختبر واسم المسؤول، ولا تستخدم رموز عملاء حقيقية في مستند عام. هذه قائمة مقترحة وليست نتائج اختبارات NxFold.

قد يعيد التبادل المباشر أخطاء مثل invalid_subject_token أو invalid_requested_token_type إذا كان الرمز غير مؤهل أو كانت المعلمات خاطئة. وقد يعيد فشل التجديد 401 مع invalid_request. اقرأ تفاصيل الخطأ؛ فليست كل استجابة 403 سببًا لإعادة مصادقة المستخدم. أخطاء الترحيل واستعادتها.

مثال افتراضي يوضح أين يقع الخطر#

لنفترض وجود تطبيق يزامن المخزون لدى 12 متجرًا، ولكل متجر رمز offline قديم دائم. فعّل الفريق إصدار رموز منتهية عند دخول المستخدمين مجددًا، لكن 7 تجار فقط فتحوا التطبيق أثناء الاختبار. تبقى 5 تثبيتات تحتاج إلى مسار موثق للترحيل دون انتظار فتح التطبيق أو مع إعادة مصادقة مناسبة. هذه الأرقام مثال توضيحي، وليست بيانات Shopify أو عميل لدى NxFold.

سجل التنفيذ المناسب يحتوي على: عدد المتاجر المتأثرة، مسار الترحيل، نسخة تخزين الاعتمادات، آخر اختبار تجديد ناجح، نتائج المهام الخلفية، المسؤول عن الاستثناء، وتاريخ المراجعة. لا تضع رمز وصول خامًا داخل التقرير.

القرار العملي الآن#

مطور التطبيق العام المتأثر: عيّن مسؤولًا فنيًا، واحصر التثبيتات ونوع الرموز، واختبر إصدار الرموز الجديدة وتخزينها وتجديدها، ثم ضع خطة للتثبيتات القديمة قبل 1 يناير. تراجعك عن نسخة كود لا يعني أنك تستطيع استعادة رمز قديم أُبطل خلال التبادل؛ حضّر خطة إعادة مصادقة عند الحاجة.

صاحب متجر يستخدم تطبيقًا جاهزًا: اطلب من مطور التطبيقات المهمة تأكيد ترحيل offline access tokens وخطة التعامل مع الانقطاع. لست مطالبًا بتغيير قالب المتجر أو بناء OAuth بنفسك. ولموضوع Shopify مختلف، اقرأ دليل Shop MCP للمساعدات الذكية أو مقارنة منصات المتاجر.

المنهجية: مراجعة إعلانات Shopify الرسمية بتاريخ 27 أكتوبر 2026 ووثائق المصادقة والتجديد، مع جدول قرار ومثال افتراضيين. لم نصل إلى رموز أي تاجر ولم نختبر ترحيلًا حقيقيًا أو نزعم تحقيق امتثال.