تشكّل هذه الصفحة جزءًا من المستندات المتعلّقة بالنظام الأساسي لتطبيقات Chrome الذي تم إيقافه في عام 2020. سيظل هذا الإصدار متاحًا لعملاء Enterprise وEducation على نظام التشغيل ChromeOS حتى كانون الثاني (يناير) 2025 على الأقل. اطّلِع على مزيد من المعلومات عن نقل بيانات تطبيقك.

تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

مصادقة المستخدم

تستخدِم بروتوكولات مصادقة الويب ميزات HTTP، ولكن يتم تشغيل تطبيقات Chrome داخل حاوية التطبيق، وبالتالي لا يتم تحميلها عبر HTTP ولا يمكنها إجراء عمليات إعادة توجيه أو ضبط ملفات تعريف الارتباط.

استخدِم Chrome Identity API لمصادقة المستخدمين: getAuthToken للمستخدمين الذين سجّلوا الدخول إلى حساباتهم على Google وlaunchWebAuthFlow للمستخدمين الذين سجّلوا الدخول إلى حساب غير تابع لشركة Google. إذا كان تطبيقك يستخدم خادمه الخاص لمصادقة المستخدمين، عليك استخدام هذا الخادم.

آلية العمل

لدى مستخدمي تطبيقات Chrome حساب Google مرتبط بملفاتهم الشخصية. يمكن للتطبيقات الحصول على رموز OAuth2 لهؤلاء المستخدمين باستخدام واجهة برمجة التطبيقات getAuthToken.

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

مصادقة حساب Google

في ما يلي الخطوات الخمس التي يجب إكمالها:

يُرجى إضافة أذونات إلى ملف البيان وتحميل تطبيقك.
انسخ المفتاح في manifest.json المثبَّت إلى ملف بيان المصدر، حتى يظل رقم تعريف التطبيق ثابتًا أثناء التطوير.
احصل على معرِّف عميل OAuth2 لتطبيق Chrome.
عدِّل ملف البيان لتضمين معرّف العميل والنطاقات.
الحصول على الرمز المميّز للمصادقة

إضافة الأذونات وتحميل التطبيق

يجب التأكد من توفُّر إذن تحديد الهوية في بيان التطبيق. يمكنك بعد ذلك تحميل تطبيقك إلى صفحة إدارة التطبيقات والإضافات (راجِع النشر).

"permissions": [
  "identity"
]

نسخ المفتاح إلى البيان

عند تسجيل تطبيقك في وحدة تحكّم Google OAuth، عليك تقديم رقم تعريف تطبيقك الذي سيتم التحقّق منه أثناء طلبات الرموز المميّزة. لذلك، من المهم استخدام قيمة متّسقة لرقم تعريف التطبيق أثناء عملية التطوير.

للحفاظ على معرّف التطبيق ثابتًا، عليك نسخ المفتاح في manifest.json المثبَّت إلى بيان المصدر. إنها ليست المهمة الأكثر رشاقة، ولكن إليك كيف تعمل:

انتقِل إلى دليل بيانات المستخدمين. مثال على نظام التشغيل MacOs: ~/Library/Application\ Support/Google/Chrome/Default/Extensions
يُرجى إدراج التطبيقات والإضافات المثبَّتة ومطابقة رقم تعريف تطبيقك في صفحة إدارة التطبيقات والإضافات مع رقم التعريف نفسه هنا.
انتقِل إلى دليل التطبيقات المثبَّتة (سيكون هذا الإصدار ضمن معرّف التطبيق). افتح manifest.json المثبّت (يشكّل pico طريقة سريعة لفتح الملف).
انسخ "المفتاح" في manifest.json المثبّت والصقه في ملف بيان المصدر لتطبيقك.

الحصول على معرِّف عميل OAuth2

عليك تسجيل تطبيقك في "وحدة تحكّم Google APIs" للحصول على معرّف العميل:

سجِّل الدخول إلى Google APIs Console باستخدام حساب Google نفسه المستخدَم لتحميل تطبيقك إلى "سوق Chrome الإلكتروني".
أنشئ مشروعًا جديدًا من خلال توسيع القائمة المنسدلة في أعلى يمين الشاشة واختيار إنشاء....
بعد إنشاء العنصر وتسميته، انتقِل إلى عنصر قائمة التنقّل "الخدمات" وفعِّل أيًّا من خدمات Google التي يحتاجها تطبيقك.
انتقِل إلى عنصر قائمة التنقّل "الوصول إلى واجهة برمجة التطبيقات" وانقر على الزرّ الأزرق إنشاء معرّف ملف تعريف العميل باستخدام OAuth 2.0....
أدخِل معلومات العلامة التجارية المطلوبة، ثم اختَر النوع التطبيق المُثبّت.
اختَر تطبيق Chrome وأدخِل رقم تعريف تطبيقك (رقم التعريف نفسه المعروض في صفحة إدارة التطبيقات والإضافات).

تعديل ملف البيان باستخدام معرِّف عميل OAuth2 والنطاقات

عليك تعديل البيان لتضمين معرّف العميل والنطاقات. في ما يلي نموذج "oauth2" ل نموذج gdrive:

"oauth2": {
    "client_id": "665859454684.apps.googleusercontent.com",
    "scopes": [
      "https://www.googleapis.com/auth/drive"
    ]
  }

الحصول على رموز الدخول

أصبحت الآن مستعدًا للحصول على رمز التفويض من خلال استدعاء identity.getAuthToken.

chrome.identity.getAuthToken({ 'interactive': true }, function(token) {
  // Use the token.
});

تفاعل المستخدم

عند استدعاء الدالة getAuthToken، يمكنك وضع علامة ('interactive': true في المثال أعلاه) تشير إلى ما إذا كنت تريد طلب واجهة برمجة التطبيقات في الوضع التفاعلي أو الوضع الصامت. في حال استدعاء واجهة برمجة التطبيقات في الوضع التفاعلي، يتم عرض واجهة مستخدم لتسجيل الدخول و/أو الموافقة على المستخدم عند الضرورة، كما هو موضّح في لقطة الشاشة أدناه:

لقطة شاشة تعرض واجهة المستخدم عندما يستخدم أحد التطبيقات Identity API لمصادقة حساب Google.

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

أفضل الممارسات التي نقترحها هي استخدام الوضع الصامت عندما لا يتم استخدام إيماءة المستخدم واستخدام الوضع التفاعلي في حال استخدام إيماءة المستخدم (على سبيل المثال، نقر المستخدم على زر "تسجيل الدخول" في تطبيقك). يُرجى العِلم بأنّنا لا نفرض أي متطلبات متعلقة بالإيماءات.

التخزين المؤقت

يحتوي Chrome على ذاكرة تخزين مؤقت لرموز الدخول، لذا يمكنك طلب getAuthToken في أي وقت تحتاج فيه إلى استخدام رمز مميز. تتعامل ذاكرة التخزين المؤقت مع تاريخ انتهاء صلاحية الرمز المميّز تلقائيًا.

يمكنك الاطّلاع على الحالة الحالية لمخزّن الرمز المميّز المؤقت على chrome://identity-internals.

في بعض الحالات، مثل عندما يغيّر المستخدم كلمة المرور، لن تعمل علامات الوصول التي لم تنته صلاحيتها. ستبدأ طلبات البيانات من واجهة برمجة التطبيقات التي تستخدم الرمز المميّز في الظهور برمز حالة HTTP 401. إذا رصدت حدوث ذلك، يمكنك إزالة الرمز المميّز غير الصالح من ذاكرة التخزين المؤقت في Chrome من خلال استدعاء identity.removeCachedAuthToken.

مثال على استخدام removeCachedAuthToken:

// callback = function (error, httpStatus, responseText);
function authenticatedXhr(method, url, callback) {
  var retry = true;
  function getTokenAndXhr() {
    chrome.identity.getAuthToken({/* details */},
                                 function (access_token) {
      if (chrome.runtime.lastError) {
        callback(chrome.runtime.lastError);
        return;
      }

      var xhr = new XMLHttpRequest();
      xhr.open(method, url);
      xhr.setRequestHeader('Authorization',
                           'Bearer ' + access_token);

      xhr.onload = function () {
        if (this.status === 401 && retry) {
          // This status may indicate that the cached
          // access token was invalid. Retry once with
          // a fresh token.
          retry = false;
          chrome.identity.removeCachedAuthToken(
              { 'token': access_token },
              getTokenAndXhr);
          return;
        }

        callback(null, this.status, this.responseText);
      }
    });
  }
}

مصادقة الحساب غير التابع لشركة Google

في ما يلي الخطوات الثلاث التي يجب إكمالها:

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

التسجيل لدى مقدّم الخدمة

وعليك تسجيل معرِّف عميل OAuth2 لدى موفّر الخدمة وإعداد معرِّف العميل كموقع إلكتروني. لإدخال معرّف الموارد المنتظم (URI) لإعادة التوجيه أثناء التسجيل، استخدِم عنوان URL للنموذج: https://<extension-id>.chromiumapp.org/<anything-here>

على سبيل المثال، إذا كان رقم تعريف تطبيقك هو abcdefghijklmnopqrstuvwxyzabcdef وأردت أن يكون provider_cb هو المسار، لتمييزه عن معرّفات الموارد المنتظمة لإعادة التوجيه من موفّري خدمات آخرين، يجب استخدام: https://abcdefghijklmnopqrstuvwxyzabcdef.chromiumapp.org/provider_cb

إضافة أذونات للموفّر

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

"permissions": [
  ...
  "https://www.website-of-provider-with-user-photos.com/photos/*"
]

الحصول على الرمز المميّز

للحصول على الرمز المميّز:

chrome.identity.launchWebAuthFlow(
  {'url': '<url-to-do-auth>', 'interactive': true},
  function(redirect_url) { /* Extract token from redirect_url */ });

يمثّل <url-to-do-auth> كل ما هو مطلوب من عنوان URL للمصادقة على موفّر الخدمة من موقع إلكتروني. على سبيل المثال، لنفترض أنّك تُجري عملية OAuth2 مع مقدّم خدمة وأنّك سجّلت تطبيقك باستخدام معرّف العميل 123456789012345 وأنّك تريد الوصول إلى صور المستخدم على موقع الموفّر الإلكتروني: https://www.website-of-provider-with-user-photos.com/dialog/oauth?client_id=123456789012345& redirect_uri=https://abcdefghijklmnopqrstuvwxyzabcdef.chromiumapp.org/provider_cb&response_type=token&scope=user_photos

سيُجري مقدّم الخدمة عملية المصادقة، وسيعرض واجهة مستخدم تسجيل الدخول و/أو الموافقة للمستخدم، إذا كان ذلك مناسبًا. ستتم بعد ذلك إعادة التوجيه إلى https://abcdefghijklmnopqrstuvwxyzabcdef.chromiumapp.org/provider_cb#authToken=<auth-token>.

سيلتقط Chrome هذا الإجراء وسيستدعي طلب إعادة الاتصال بالتطبيق باستخدام عنوان URL الكامل لإعادة التوجيه. يجب أن يستخرج التطبيق الرمز المميّز من عنوان URL.

الوضع التفاعلي في مقابل الوضع الصامت

عند استدعاء launchWebAuthFlow، يمكنك تمرير علامة ('interactive': true في المثال أعلاه) تشير إلى ما إذا كنت تريد استدعاء واجهة برمجة التطبيقات في الوضع التفاعلي أم لا (المعروف أيضًا باسم الوضع الصامت). إذا كنت تستدعي واجهة برمجة التطبيقات في الوضع التفاعلي، يتم عرض واجهة مستخدم للمستخدم، إذا لزم الأمر، للحصول على الرمز المميّز (واجهة مستخدم تسجيل الدخول و/أو واجهة مستخدم الموافقة أو أي واجهة مستخدم خاصة بالموفّر).

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

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