จัดการกับการละเมิดโค้ดที่โฮสต์จากระยะไกล

โค้ดที่โฮสต์จากระยะไกลหรือ RHC คือสิ่งที่ Chrome เว็บสโตร์เรียกว่าทุกอย่างที่ เบราว์เซอร์ดำเนินการซึ่งโหลดจากที่อื่นที่ไม่ใช่ ไฟล์ของส่วนขยายเอง เช่น JavaScript และ WASM แต่ไม่รวมถึงข้อมูลหรือสิ่งต่างๆ เช่น JSON หรือ CSS

เหตุใดจึงไม่อนุญาตให้ใช้ RHC อีกต่อไป

ส่วนขยายที่ใช้ Manifest V3 ต้องรวมโค้ดทั้งหมดที่ใช้ไว้ภายใน ส่วนขยายเอง ในอดีต คุณสามารถแทรกแท็กสคริปต์แบบไดนามิกจาก URL ใดก็ได้บนเว็บ

ฉันได้รับแจ้งว่าส่วนขยายของฉันมี RHC เกิดอะไรขึ้น

หากส่วนขยายถูกปฏิเสธระหว่างการตรวจสอบเนื่องจากข้อผิดพลาด Blue Argon แสดงว่า ผู้ตรวจสอบเชื่อว่าส่วนขยายของคุณใช้โค้ดที่โฮสต์จากระยะไกล โดยปกติแล้วปัญหานี้เกิดจากส่วนขยายที่พยายามเพิ่มแท็กสคริปต์ที่มีแหล่งข้อมูลระยะไกล (เช่น จากเว็บแบบเปิด แทนที่จะเป็นไฟล์ที่รวมอยู่ในส่วนขยาย) หรือการดึงข้อมูลทรัพยากรเพื่อดำเนินการโดยตรง

วิธีสังเกต RHC

การสังเกต RHC ไม่ใช่เรื่องยากนักเมื่อคุณรู้ว่าต้องมองหาอะไร ก่อนอื่น ให้ ตรวจสอบสตริง "http://" หรือ "https://" ในโปรเจ็กต์ หากมีการละเมิด RHC คุณน่าจะค้นหาได้โดยการค้นหาการละเมิดดังกล่าว หากคุณมีระบบบิลด์แบบเต็ม หรือใช้การขึ้นต่อกันจาก npm หรือแหล่งที่มาอื่นๆ ของบุคคลที่สาม โปรดตรวจสอบว่าคุณกำลังค้นหาโค้ดเวอร์ชันที่คอมไพล์ เนื่องจากเป็นเวอร์ชันที่ร้านค้าจะประเมิน หากยังคงพบปัญหาอยู่ ขั้นตอนถัดไปคือการติดต่อOne Stop Support โดยจะสามารถระบุการละเมิดที่เฉพาะเจาะจง และสิ่งที่จำเป็นต่อการเผยแพร่ส่วนขยายโดยเร็วที่สุด

สิ่งที่ต้องทำหากห้องสมุดขอรหัส

ไม่ว่าจะมาจากที่ใดก็ตาม ไม่อนุญาตให้มี RHC ซึ่งรวมถึงโค้ดที่คุณไม่ได้เขียนเอง แต่ใช้เป็นทรัพยากร Dependency ในโปรเจ็กต์ นักพัฒนาแอปบางรายที่ใช้ Firebase พบปัญหานี้เมื่อมีการรวมโค้ดระยะไกล เพื่อใช้ใน Firebase Auth แม้ว่าจะเป็นไลบรารีของ บุคคลที่หนึ่ง (กล่าวคือ Google เป็นเจ้าของ) แต่ RHC ก็ไม่มีข้อยกเว้น คุณต้อง กำหนดค่าโค้ดเพื่อนำ RHC ออก หรืออัปเดตโปรเจ็กต์ไม่ให้ รวมโค้ดตั้งแต่แรก หากพบปัญหาที่ไม่ได้เกิดจากโค้ดของคุณ ที่โหลด RHC แต่เกิดจากไลบรารีที่คุณใช้ แนวทางที่ดีที่สุด คือการติดต่อผู้เขียนไลบรารี แจ้งให้ผู้ให้บริการทราบว่าเกิดปัญหานี้ และขอวิธีแก้ปัญหาหรือการอัปเดตโค้ดเพื่อนำออก

จะเกิดอะไรขึ้นหากคุณรอการอัปเดตไลบรารีไม่ได้

ไลบรารีบางแห่งจะจัดส่งการอัปเดตทันทีหลังจากได้รับการแจ้งเตือน แต่ ไลบรารีอื่นๆ อาจถูกละเลยหรือใช้เวลาในการแก้ไขปัญหา คุณอาจไม่ต้องรอให้สิ่งที่ เกิดขึ้นในการละเมิดที่เฉพาะเจาะจงย้ายไปเพื่อปลดบล็อกและทำการตรวจสอบให้เสร็จสมบูรณ์ คุณมี ตัวเลือกมากมายที่จะช่วยให้กลับมาใช้งานได้อีกครั้งอย่างรวดเร็ว

ตรวจสอบโค้ด

คุณแน่ใจไหมว่าโค้ดที่ทำให้เกิดคำขอเป็นโค้ดที่จำเป็น หากลบได้ หรือนำไลบรารีที่ทำให้เกิดข้อผิดพลาดออกได้ ให้ลบโค้ดนั้น แล้วก็เป็นอันเสร็จ

หรือมีไลบรารีอื่นที่ให้บริการฟีเจอร์เดียวกันไหม ลองดูตัวเลือกอื่นๆ ที่ตรงกับ Use Case เดียวกันได้ที่ npmjs.com, GitHub หรือเว็บไซต์อื่นๆ

เขย่าต้นไม้

หากไม่ได้ใช้โค้ดที่ทำให้เกิดการละเมิด RHC จริงๆ เครื่องมืออาจลบโค้ดดังกล่าวโดยอัตโนมัติได้ เครื่องมือบิลด์ที่ทันสมัย เช่น webpack, Rollup และ Vite (ยกตัวอย่างมาเพียงไม่กี่รายการ) มีฟีเจอร์ที่เรียกว่า tree-shaking เมื่อเปิดใช้ในระบบบิลด์แล้ว Tree Shaking ควรนำเส้นทางโค้ดที่ไม่ได้ใช้ออก ซึ่งหมายความว่าคุณไม่เพียงแต่มีโค้ดเวอร์ชันที่ เป็นไปตามข้อกำหนดมากขึ้น แต่ยังมีโค้ดที่กระชับและเร็วขึ้นด้วย โปรดทราบว่าไลบรารีบางรายการไม่สามารถทำการ Tree Shaking ได้ แต่หลายรายการทำได้ เครื่องมือบางอย่าง เช่น Rollup และ Vite จะเปิดใช้ Tree Shaking โดยค่าเริ่มต้น ส่วน webpack ต้องได้รับการกำหนดค่าจึงจะเปิดใช้ได้ หากคุณไม่ได้ใช้ระบบบิลด์เป็นส่วนหนึ่งของส่วนขยาย แต่ใช้ไลบรารีโค้ด เราขอแนะนำให้คุณพิจารณาเพิ่มเครื่องมือบิลด์ลงในเวิร์กโฟลว์ เครื่องมือ บิลด์ช่วยให้คุณเขียนโปรเจ็กต์ที่ปลอดภัย เชื่อถือได้ และบำรุงรักษาได้มากขึ้น

รายละเอียดวิธีใช้ Tree Shaking จะขึ้นอยู่กับโปรเจ็กต์ของคุณ แต่หากจะยกตัวอย่างง่ายๆ ด้วย Rollup คุณสามารถเพิ่มการกำจัดโค้ดที่ไม่ได้ใช้ได้เพียงแค่ คอมไพล์โค้ดโปรเจ็กต์ เช่น หากคุณมีไฟล์ที่บันทึกเฉพาะใน Firebase Auth ชื่อ main.js

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

browser.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

การสรุปอาจดูเรียบง่าย แต่ก็กำหนดค่าได้มากเช่นกัน คุณเพิ่มตรรกะและการกำหนดค่าที่ซับซ้อนได้ทุกประเภท เพียงดูเอกสารประกอบ การเพิ่มเครื่องมือสร้างอย่างนี้จะทำให้โค้ดมีขนาดเล็กลงและมีประสิทธิภาพมากขึ้น และในกรณีนี้จะช่วยแก้ไขปัญหาโค้ดที่โฮสต์จากระยะไกล

การแก้ไขไฟล์โดยอัตโนมัติ

วิธีที่โค้ดที่โฮสต์จากระยะไกลสามารถเข้าสู่ฐานของโค้ดของคุณได้ซึ่งพบเห็นได้มากขึ้นเรื่อยๆ คือ เป็นทรัพยากรย่อยของไลบรารีที่คุณรวมไว้ หากไลบรารี X ต้องการimportไลบรารี Y จาก CDN คุณจะต้องอัปเดตไลบรารีเพื่อให้โหลดจากแหล่งที่มาในเครื่อง ระบบบิลด์สมัยใหม่ช่วยให้คุณสร้างปลั๊กอินเพื่อดึงข้อมูลอ้างอิงระยะไกลและแทรกลงในโค้ดได้โดยตรง

ซึ่งหมายความว่าหากมีโค้ดที่มีลักษณะดังนี้

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
    }
  }]
};

เมื่อเรียกใช้บิลด์ด้วยปลั๊กอินใหม่แล้ว ระบบจะค้นพบ import URL ระยะไกลทุกรายการ ไม่ว่าจะเป็นโค้ดของเรา การขึ้นต่อกันย่อย การขึ้นต่อกันย่อยๆ หรือที่อื่นๆ

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 จะช่วยให้การจัดการแพตช์ง่ายขึ้นมาก แต่การไม่มีอะไรให้แพตช์ก็ดียิ่งกว่า

สิ่งที่ควรทำหากไม่ได้ใช้รหัส

เมื่อฐานของโค้ดมีขนาดใหญ่ขึ้น ทรัพยากร Dependency (หรือทรัพยากร Dependency ของทรัพยากร Dependency หรือทรัพยากร Dependency ของ…) อาจทำให้เส้นทางโค้ดที่ไม่ได้ใช้แล้วยังคงอยู่ หากส่วนใดส่วนหนึ่งมีโค้ดสำหรับโหลดหรือเรียกใช้ RHC คุณจะต้องนำโค้ดนั้นออก ไม่ว่าแบตเตอรี่จะหมดหรือไม่ได้ใช้งานก็ตาม หากไม่ได้ใช้งาน ควรนำออกโดยใช้การกำจัดโค้ดที่ไม่จำเป็น หรือแก้ไขไลบรารีเพื่อนำออก

มีวิธีแก้ปัญหาใดๆ ไหม

โดยทั่วไปแล้วไม่อนุญาตให้ใช้ RHC อย่างไรก็ตาม มีบางกรณีที่อนุญาต ซึ่งมักจะเป็นกรณีที่ตัวเลือกอื่น เป็นไปไม่ได้

User Scripts API

สคริปต์ของผู้ใช้คือข้อมูลโค้ดขนาดเล็กที่มักจะมาจากผู้ใช้ ซึ่งมีไว้สำหรับตัวจัดการสคริปต์ของผู้ใช้ เช่น TamperMonkey และ Violentmonkey เครื่องมือจัดการเหล่านี้ไม่สามารถรวมโค้ดที่ผู้ใช้เขียนได้ ดังนั้น User Script API จึงแสดงวิธีเรียกใช้โค้ดที่ผู้ใช้ระบุ ฟีเจอร์นี้ไม่ใช่ตัวแทนของ browser.scripting.executeScript หรือสภาพแวดล้อมการเรียกใช้โค้ดอื่นๆ ผู้ใช้ต้องเปิดใช้โหมดนักพัฒนาซอฟต์แวร์เพื่อดำเนินการใดๆ หากทีมตรวจสอบของ Chrome เว็บสโตร์คิดว่ามีการใช้ฟีเจอร์นี้ในลักษณะอื่นนอกเหนือจากที่ตั้งใจไว้ (เช่น โค้ดที่ผู้ใช้ระบุ) ระบบอาจปฏิเสธหรือนำข้อมูลของส่วนขยายออกจากร้านค้า

browser.debugger

API browser.debugger ช่วยให้ส่วนขยายโต้ตอบกับโปรโตคอลเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ได้ ซึ่งเป็นโปรโตคอลเดียวกับที่ใช้สำหรับ เครื่องมือสำหรับนักพัฒนาเว็บของ Chrome และเครื่องมืออื่นๆ อีกมากมาย ซึ่งช่วยให้ส่วนขยาย ขอและเรียกใช้โค้ดจากระยะไกลได้ เช่นเดียวกับสคริปต์ของผู้ใช้ สคริปต์นี้ไม่ใช่ ตัวแทนของ browser.scripting และมีประสบการณ์ของผู้ใช้ที่โดดเด่นกว่ามาก ขณะใช้งาน ผู้ใช้จะเห็นแถบคำเตือนที่ด้านบนของหน้าต่าง หากปิดหรือปิดแบนเนอร์ เซสชันการแก้ไขข้อบกพร่องจะสิ้นสุด

iframe ที่แซนด์บ็อกซ์

หากต้องการประเมินสตริงเป็นโค้ดและอยู่ในสภาพแวดล้อม DOM (เช่น สคริปต์เนื้อหา ซึ่งตรงข้ามกับ Service Worker ของส่วนขยาย) อีกทางเลือกหนึ่งคือการใช้ iframe ที่แซนด์บ็อกซ์ ส่วนขยายไม่รองรับสิ่งต่างๆ เช่น eval() โดยค่าเริ่มต้นเพื่อเป็นการป้องกันด้านความปลอดภัย โค้ดที่เป็นอันตรายอาจทำให้ความปลอดภัย ของผู้ใช้มีความเสี่ยง แต่เมื่อมีการเรียกใช้โค้ดในสภาพแวดล้อมที่ปลอดภัยที่ทราบเท่านั้น เช่น iframe ที่ได้รับการแซนด์บ็อกซ์จากส่วนอื่นๆ ของเว็บ ความเสี่ยงเหล่านั้นก็จะลดลงอย่างมาก ในบริบทนี้ คุณสามารถยกเลิกนโยบายรักษาความปลอดภัยเนื้อหาที่บล็อกการใช้ eval เพื่อให้คุณเรียกใช้โค้ด JavaScript ที่ถูกต้องได้

หากคุณมีกรณีการใช้งานที่ไม่ได้ครอบคลุม โปรดติดต่อทีม โดยใช้รายชื่ออีเมล chromium-extensions เพื่อรับความคิดเห็น หรือเปิด คำขอใหม่เพื่อขอคำแนะนำจาก One Stop Support

สิ่งที่ควรทำหากไม่เห็นด้วยกับคำตัดสิน

การบังคับใช้นโยบายอาจมีความแตกต่างกันเล็กน้อย และการตรวจสอบต้องมีการป้อนข้อมูลด้วยตนเอง ซึ่งหมายความว่า ทีม Chrome เว็บสโตร์อาจเห็นด้วยที่จะเปลี่ยนคำตัดสินในการตรวจสอบในบางครั้ง หากเชื่อว่าการตรวจสอบเกิดจากข้อผิดพลาด คุณสามารถอุทธรณ์การปฏิเสธได้ โดยใช้การสนับสนุนแบบครบวงจร