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

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

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

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

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

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

איך לזהות RHC

לא קשה במיוחד לזהות RHC ברגע שאתם יודעים מה לחפש. קודם כל, מחפשים את המחרוזות "http:// " או "https:// " בפרויקט שלך. אם יש לך ב-RHC, סביר להניח שתוכלו לאתר אותם באמצעות גילוי כך. אם המיקום שיש לכם מערכת build מלאה או יחסי תלות מ-npm מקורות צד, ודאו שאתם מחפשים את הגרסה המורכבת של הקוד, כי זה מה שהחנות בודקת. אם עדיין לא הצלחתם מאתרים את הבעיה. השלב הבא הוא לפנות לתמיכה של OneStop. הם עליו לפרט את ההפרות הספציפיות, ומה נדרש כדי שיפורסם בהקדם האפשרי.

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

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

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

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

בדיקת הקוד

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

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

עצים רועדים

אם לא נעשה שימוש בקוד שגורם להפרת ה-RHC, ייתכן נמחקת באופן אוטומטי באמצעות כלים. כלי build מודרניים כמו ל-webpack, ל-Rollup ול-Vite יש תכונה שנקראת רעידת עץ. אחרי ההפעלה במערכת ה-build, רעידת עץ צריך להסיר את כל נתיבי הקוד שלא נמצאים בשימוש. כלומר, לא רק שיש תואם לקוד שלך, אבל גם גרסה מדויקת יותר ומהירה יותר! חשוב שימו לב שלא כל הספריות יכולות לקבל רעידות עץ, אבל רבות מהן כן. במידה מסוימת בכלים שונים, כמו 'רשימה כללית' ו-'Vit', רעידת עצים מופעלת כברירת מחדל. חבילה ו-Webpack צריך להגדיר אותו כדי שהוא יופעל. אם לא משתמשים ב-build כחלק מהתוסף, אבל משתמשים בספריות קוד, אז אתם מומלץ מאוד להוסיף כלי build לתהליך העבודה שלך. פיתוח פתרונות שיעזרו לכם לכתוב פרויקטים בטוחים, אמינים וקלים יותר לתחזוקה.

אופן ההטמעה של רעידות עצים תלוי בפרויקט הספציפי שלכם. לדוגמה, באמצעות אוסף ערוצים, אפשר להוסיף רעידת עצים ההידור של קוד הפרויקט. לדוגמה, אם יש לך קובץ שמתחבר רק אל Firebase Auth, שנקרא primary.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);
  }
});

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

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

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

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

עריכה אוטומטית של קבצים

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

המשמעות היא שהקוד הנתון שנראה כך:

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

אפשר ליצור פלאגין קטן לאוסף ערוצים.

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. צריך רק לשנות באופן ידני את הקוד שמפר את המדיניות, לשמור את קובץ ההבדלים ולהגדיר patch-package עם השינויים שרוצים להחיל. אפשר לקרוא את המדריך המלא ב-readme של הפרויקט. אם אתם מתקנים פרויקט, אנחנו באמת מומלץ לפנות לפרויקט כדי לבקש שיבוצעו שינויים פליטת גז חממה. חבילת תיקון מפשטת הרבה יותר את ניהול התיקונים, אין מה לתקן, זה אפילו יותר טוב.

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

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

האם יש דרך כלשהי לעקוף את הבעיה?

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

ממשק API של סקריפטים של משתמש

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

chrome.debugger

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

צילום מסך של סרגל הכתובות ב-Chrome עם ההודעה 'התוסף לניפוי באגים התחיל לנפות באגים בדפדפן הזה'

iframes בארגז חול (Sandbox)

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

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

מה לעשות אם אתם לא מסכימים עם החלטה שהתקבלה

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