טיפול בהפרות של קוד באירוח מרוחק

קוד שמתארח מרחוק, או RHC, הוא השם שחנות האינטרנט של Chrome נותנת לכל דבר שמופעל על ידי הדפדפן ונטען ממקום אחר ולא מהקבצים של התוסף עצמו. למשל JavaScript ו-WASM. הוא לא כולל נתונים או דברים כמו JSON או CSS.

למה אסור יותר להשתמש ב-RHC?

בתוספים עם Manifest V3, צריך עכשיו לאגד את כל הקוד שבו משתמשים בתוך התוסף עצמו. בעבר, הייתה אפשרות להחדיר באופן דינמי תגי סקריפט מכל כתובת URL באינטרנט.

נאמר לי שהתוסף שלי כולל RHC. מה הבעיה?

אם התוסף שלך נדחה במהלך הבדיקה בגלל שגיאת Blue Argon, המשמעות היא שהבודקים שלנו סבורים שהתוסף משתמש בקוד שמתארח מרחוק. בדרך כלל, השגיאה הזו מתרחשת כשתוסף מנסה להוסיף תג סקריפט עם משאב מרוחק (כלומר, מהאינטרנט הפתוח, ולא מהקבצים שנכללים בתוסף), או לאחזר משאב כדי להפעיל אותו ישירות.

איך מזהים RHC

לא קשה לזהות תוכן שנוצר על ידי AI אם יודעים מה לחפש. קודם כול, בודקים אם המחרוזות 'http://‎' או 'https://‎' מופיעות בפרויקט. אם יש לכם הפרה של RHC, סביר להניח שתוכלו לאתר אותה. אם יש לכם מערכת build מלאה, או אם אתם משתמשים בתלויות מ-npm או ממקורות אחרים של צד שלישי, הקפידו לחפש את הגרסה המהודרת של הקוד, כי זו הגרסה שנבדקת על ידי החנות. אם עדיין לא הצלחתם למצוא את הבעיה, השלב הבא הוא לפנות אל One Stop Support. הם יוכלו לפרט את ההפרות הספציפיות ולציין מה צריך לעשות כדי לפרסם את התוסף בהקדם האפשרי.

מה עושים אם ספרייה מבקשת את הקוד

לא משנה מאיפה הקוד מגיע, אסור שהוא יכיל RHC. זה כולל קוד שלא כתבתם, אבל אתם משתמשים בו כתלות בפרויקט. חלק מהמפתחים שמשתמשים ב-Firebase נתקלו בבעיה הזו כשקוד מרחוק נכלל לשימוש ב-Firebase Auth. למרות שמדובר בספרייה של צד ראשון (כלומר בבעלות Google), לא ניתן חריג ל-RHC. צריך להגדיר את הקוד כך שה-RHC יוסר, או לעדכן את הפרויקט כך שהקוד לא ייכלל בו מלכתחילה. אם נתקלתם בבעיה שבה לא קוד שלכם טוען את RHC, אלא ספרייה שבה אתם משתמשים, הפעולה הכי טובה היא לפנות ליוצר הספרייה. צריך להודיע להם על כך ולבקש מהם פתרון עקיף או עדכוני קוד כדי להסיר את ההודעה.

מה קורה אם לא רוצים לחכות לעדכון של הספרייה

חלק מהספריות יעדכנו את עצמן כמעט מיד אחרי קבלת ההודעה, אבל יכול להיות שספריות אחרות לא יתעדכנו או שייקח זמן עד שהבעיה תיפתר. בהתאם למה קורה בהפרה הספציפית, יכול להיות שלא תצטרכו לחכות עד שההפרה תעבור לבדיקה ותושלם בהצלחה כדי לבטל את החסימה. יש כמה אפשרויות שיעזרו לכם לחזור לפעילות במהירות.

ביקורת על הקוד

האם אתם בטוחים שהקוד שגורם לבקשה נחוץ? אם אפשר פשוט למחוק את הקוד או להסיר את הספרייה שגורמת לבעיה, אז מוחקים את הקוד והבעיה נפתרת.

לחלופין, האם יש ספרייה אחרת שמציעה את אותן תכונות? אפשר לנסות לבדוק ב-npmjs.com, ב-GitHub או באתרים אחרים אם יש אפשרויות אחרות שמתאימות לאותם תרחישי שימוש.

ניעור עצים

אם הקוד שגורם להפרה של כללי המדיניות בנושא RHC לא נמצא בשימוש בפועל, יכול להיות שהכלי יוכל למחוק אותו באופן אוטומטי. בכלי בנייה מודרניים כמו webpack,‏ Rollup ו-Vite (אלה רק כמה דוגמאות) יש תכונה שנקראת tree-shaking. אחרי שמפעילים את tree shaking במערכת ה-build, היא אמורה להסיר את כל נתיבי הקוד שלא נמצאים בשימוש. יכול להיות שתקבלו לא רק גרסה תואמת יותר של הקוד, אלא גם גרסה יעילה ומהירה יותר. חשוב לציין שלא כל הספריות ניתנות ל-tree shaking, אבל רבות כן. בכמה כלים, כמו Rollup ו-Vite, האפשרות tree-shaking מופעלת כברירת מחדל. כדי להפעיל אותה ב-webpack, צריך להגדיר את הכלי. אם אתם לא משתמשים במערכת build כחלק מהתוסף, אבל כן משתמשים בספריות קוד, מומלץ מאוד לבדוק אפשרות להוסיף כלי build לתהליך העבודה. הכלים של Build עוזרים לכתוב פרויקטים בטוחים, אמינים וקלים יותר לתחזוקה.

הפרטים הספציפיים של אופן ההטמעה של treeshaking תלויים בפרויקט הספציפי שלכם. אבל כדי לתת דוגמה פשוטה עם Rollup, אפשר להוסיף treeshaking רק על ידי קומפילציה של קוד הפרויקט. לדוגמה, אם יש לכם קובץ שמתעד רק כניסה ל-Firebase Auth, שנקרא main.js:

import { GoogleAuthProvider, initializeAuth } from "firebase/auth";

chrome.identity.getAuthToken({ 'interactive': true }, async (token) => {
  const credential = GoogleAuthProvider.credential(null, token);
  try {
    const app = initializeApp({ ... });
    const auth = initializeAuth(app, { popupRedirectResolver: undefined, persistence: indexDBLocalPersistence });
    const { user } = await auth.signInWithCredential(credential)
    console.log(user)
  } catch (e) {
    console.error(error);
  }
});

לאחר מכן, כל מה שצריך לעשות הוא לציין ל-Rollup את קובץ הקלט, פלאגין שנדרש לטעינת קבצי צומת ‎@rollup/plugin-node-resolve ואת שם קובץ הפלט שהוא יוצר.

npx rollup --input main.js --plugin '@rollup/plugin-node-resolve' --file compiled.js

אם מריצים את הפקודה הזו בחלון מסוף, מקבלים גרסה שנוצרה של הקובץ main.js, שכולה מקומפלת לקובץ אחד בשם compiled.js.

סיכום יכול להיות פשוט, אבל הוא גם ניתן להגדרה מאוד. אפשר להוסיף כל מיני לוגיקה והגדרות מורכבות. כדאי לעיין במסמכים שלהם. הוספה של כלי בנייה כאלה תגרום לקוד קטן ויעיל יותר, ובמקרה הזה, תפתור את הבעיה שלנו עם קוד באירוח מרוחק.

עריכת קבצים באופן אוטומטי

דרך נפוצה יותר ויותר שבה קוד שמתארח מרחוק יכול להיכנס לבסיס הקוד שלכם היא כ-subdependency של ספרייה שאתם כוללים. אם ספרייה X רוצה לטעון ספרייה Y מ-CDN, עדיין תצטרכו לעדכן אותה כדי שהיא תיטען ממקור מקומי.import במערכות build מודרניות, אפשר ליצור בקלות פלאגינים לחילוץ הפניה מרוחקת ולהטמיע אותה ישירות בקוד.

כלומר, אם יש לכם קוד שנראה כך:

import moment from "https://unpkg.com/moment@2.29.4/moment.js"
console.log(moment())

אפשר ליצור תוסף קטן של Rollup.

import { existsSync } from 'fs';
import fetch from 'node-fetch';

export default {
  plugins: [{
    load: async function transform(id, options, outputOptions) {
      // this code runs over all of out javascript, so we check every import
      // to see if it resolves as a local file, if that fails, we grab it from
      // the network using fetch, and return the contents of that file directly inline
      if (!existsSync(id)) {
        const response = await fetch(id);
        const code = await response.text();

        return code
      }
      return null
    }
  }]
};

אחרי שמריצים את ה-build עם הפלאגין החדש, כל כתובת URL מרוחקת של import מתגלה, בלי קשר לשאלה אם היא הייתה הקוד שלנו, תלות משנית, תלות משנית משנית או כל מקום אחר.

npx rollup --input main.js --config ./rollup.config.mjs --file compiled.js

עריכה ידנית של קבצים

האפשרות הכי פשוטה היא פשוט למחוק את הקוד שגורם ל-RHC. פותחים את הקובץ בכלי לעריכת טקסט שבוחרים ומוחקים את השורות שמפירות את המדיניות. בדרך כלל לא מומלץ לעשות את זה, כי זה לא יציב ויכול להיות שתשכחו מזה. אם קובץ בשם library.min.js הוא לא באמת library.min.js, יהיה קשה יותר לתחזק את הפרויקט. במקום לערוך את קובצי המקור, אפשר להשתמש בכלי כמו patch-package. זו אפשרות קלה יותר לתחזוקה. זו אפשרות שימושית במיוחד שמאפשרת לשמור שינויים בקובץ, ולא את הקובץ עצמו. הוא מבוסס על קבצי תיקון, כמו מערכות לניהול גרסאות כמו Git או Subversion. פשוט משנים ידנית את הקוד שמפר את המדיניות, שומרים את קובץ ה-diff ומגדירים את patch-package עם השינויים שרוצים להחיל. אפשר לקרוא הדרכה מלאה ב-README של הפרויקט. אם אתם מבצעים תיקון בפרויקט, אנחנו ממליצים מאוד לפנות לפרויקט ולבקש לבצע שינויים במעלה הזרם. הכלי patch-package מקל מאוד על ניהול תיקונים, אבל הכי טוב זה לא להצטרך לתקן כלום.

מה עושים אם הקוד לא נמצא בשימוש

ככל שבסיסי הקוד גדלים, יחסי תלות (או תלות בתלות, או תלות ב…) יכולים לשמור על נתיבי קוד שכבר לא נמצאים בשימוש. אם אחד מהחלקים האלה כולל קוד לטעינה או להפעלה של RHC, צריך להסיר אותו. לא משנה אם הוא לא פעיל או לא בשימוש. אם לא משתמשים בה, צריך להסיר אותה באמצעות treeshaking או תיקון של הספרייה.

האם יש פתרון עקיף כלשהו?

באופן כללי, לא. אסור להשתמש ב-RHC. עם זאת, יש מספר קטן של מקרים שבהם מותר להשתמש בשיטה הזו. כמעט תמיד מדובר במקרים שבהם אין אפשרות אחרת.

User Scripts API

סקריפטים של משתמשים הם קטעי קוד קטנים שבדרך כלל מסופקים על ידי המשתמש, ומיועדים למנהלי סקריפטים של משתמשים כמו TamperMonkey ו-Violentmonkey. מנהלי התוספים האלה לא יכולים לאגד קוד שנכתב על ידי משתמשים, ולכן ממשק ה-API של סקריפטים למשתמשים מאפשר להריץ קוד שסופק על ידי המשתמש. השימוש ב-executeScript לא מחליף את השימוש ב-chrome.scripting.executeScript או בסביבות אחרות להרצת קוד. כדי להריץ משהו, המשתמשים צריכים להפעיל את מצב פיתוח. אם צוות הביקורת של חנות האינטרנט של Chrome יחשוב שהתוסף הזה משמש למטרה אחרת מזו שהוא נועד לה (כלומר, קוד שסופק על ידי המשתמש), יכול להיות שהבקשה תדחה או שהתוסף יוסר מהחנות.

chrome.debugger

ממשק ה-API‏ chrome.debugger מאפשר לתוספים לבצע אינטראקציה עם פרוטוקול כלי הפיתוח ל-Chrome. זהו אותו פרוטוקול שמשמש את כלי הפיתוח של Chrome ומספר עצום של כלים אחרים. באמצעותו, תוסף יכול לבקש ולהריץ קוד מרחוק. בדומה לסקריפטים של משתמשים, הוא לא תחליף ל-chrome.scripting, והוא מספק חוויית משתמש הרבה יותר משמעותית. במהלך השימוש, המשתמש יראה סרגל אזהרה בחלק העליון של החלון. אם הבאנר ייסגר או יידחה, סשן הניפוי באגים יסתיים.

Sandboxed iframes

אם אתם צריכים להעריך מחרוזת כקוד, ואתם נמצאים בסביבת DOM (לדוגמה, סקריפט תוכן, בניגוד לקובץ שירות של תוסף), אפשרות נוספת היא להשתמש ב-iframe עם ארגז חול. כדי לשמור על הבטיחות, התוספים לא תומכים בדברים כמו eval() כברירת מחדל. קוד זדוני עלול לסכן את הבטיחות והאבטחה של המשתמשים. אבל אם הקוד מופעל רק בסביבה בטוחה מוכרת, כמו iframe שמוגדר כארגז חול (sandbox) מיתר האינטרנט, הסיכונים האלה מצטמצמים מאוד. בהקשר הזה, אפשר לבטל את מדיניות אבטחת התוכן שחוסמת את השימוש ב-eval, וכך להריץ כל קוד JavaScript תקין.

אם יש לכם תרחיש שימוש שלא מופיע כאן, אתם יכולים לפנות לצוות באמצעות רשימת התפוצה chromium-extensions כדי לקבל משוב, או לפתוח כרטיס חדש כדי לבקש הדרכה מOne Stop Support.

מה עושים אם לא מסכימים עם פסק הדין

אכיפת המדיניות היא תהליך מורכב, והבדיקה כוללת קלט ידני. לכן, יכול להיות שצוות חנות האינטרנט של Chrome יסכים לפעמים לשנות החלטה לגבי ביקורת. אם לדעתכם חלה טעות בתהליך הבדיקה, אתם יכולים לערער על הדחייה באמצעות התמיכה המרכזית.