रिमोट होस्ट किए गए कोड से जुड़े उल्लंघनों से निपटें

रिमोटली होस्ट किया गया कोड (आरएचसी) वह कोड होता है जिसे Chrome Web Store, ब्राउज़र के ज़रिए एक्ज़ीक्यूट होने वाले किसी भी कोड को कहता है. यह कोड, एक्सटेंशन की अपनी फ़ाइलों के अलावा किसी और जगह से लोड होता है. जैसे, JavaScript और WASM. इसमें JSON या सीएसएस जैसे डेटा या चीज़ें शामिल नहीं होती हैं.

अब आरएचसी की अनुमति क्यों नहीं है?

मेनिफ़ेस्ट V3 वाले एक्सटेंशन को अब एक्सटेंशन में इस्तेमाल किए जा रहे सभी कोड को बंडल करना होगा. पहले, वेब पर मौजूद किसी भी यूआरएल से स्क्रिप्ट टैग को डाइनैमिक तौर पर इंजेक्ट किया जा सकता था.

मुझे बताया गया है कि मेरे एक्सटेंशन में आरएचसी है. आपको कम्यूनिटी दिशा-निर्देशों और नीतियों का उल्लंघन करने वाला किस तरह का कॉन्टेंट मिला?

अगर समीक्षा के दौरान, Blue Argon गड़बड़ी की वजह से आपके एक्सटेंशन को अस्वीकार कर दिया गया है, तो इसका मतलब है कि हमारे समीक्षकों को लगता है कि आपका एक्सटेंशन, रिमोटली होस्ट किए गए कोड का इस्तेमाल कर रहा है. आम तौर पर, ऐसा तब होता है, जब कोई एक्सटेंशन रिमोट रिसॉर्स (यानी कि ओपन वेब से, न कि एक्सटेंशन में शामिल फ़ाइलों से) के साथ स्क्रिप्ट टैग जोड़ने की कोशिश करता है या सीधे तौर पर किसी रिसॉर्स को फ़ेच करता है.

आरएचसी की पहचान कैसे करें

आरएचसी को पहचानना मुश्किल नहीं है. इसके लिए, आपको यह पता होना चाहिए कि क्या देखना है. सबसे पहले, अपने प्रोजेक्ट में "http://" या "https://" स्ट्रिंग देखें. अगर आपने आरएचसी का उल्लंघन किया है, तो आपको इसकी जानकारी मिल जाएगी. अगर आपके पास पूरा बिल्ड सिस्टम है या npm या तीसरे पक्ष के अन्य सोर्स से डिपेंडेंसी का इस्तेमाल किया जाता है, तो पक्का करें कि कोड के कंपाइल किए गए वर्शन को खोजा जा रहा हो. ऐसा इसलिए, क्योंकि स्टोर इसी वर्शन का आकलन करता है. अगर आपको अब भी समस्या का पता नहीं चल पा रहा है, तो अगला चरण वन स्टॉप सपोर्ट से संपर्क करना है. वे आपको खास उल्लंघनों के बारे में बता पाएंगे. साथ ही, यह भी बता पाएंगे कि एक्सटेंशन को जल्द से जल्द पब्लिश करने के लिए क्या करना होगा.

अगर कोई लाइब्रेरी कोड का अनुरोध कर रही है, तो क्या करें

कोड कहीं से भी मिला हो, लेकिन उसमें आरएचसी नहीं होना चाहिए. इसमें वह कोड भी शामिल है जिसे आपने नहीं लिखा है, लेकिन आपने उसे अपने प्रोजेक्ट में डिपेंडेंसी के तौर पर इस्तेमाल किया है. कुछ डेवलपर को यह समस्या तब आई, जब Firebase Auth में इस्तेमाल करने के लिए रिमोट कोड शामिल किया जा रहा था. ये डेवलपर, Firebase का इस्तेमाल कर रहे थे. भले ही, यह पहली पार्टी (यानी कि Google के मालिकाना हक वाली) लाइब्रेरी थी, लेकिन RHC के लिए कोई अपवाद नहीं दिया गया है. आपको कोड को कॉन्फ़िगर करना होगा, ताकि आरएचसी को हटाया जा सके. इसके अलावा, आपको अपने प्रोजेक्ट को अपडेट करना होगा, ताकि कोड को शामिल न किया जा सके. अगर आपको ऐसी समस्या आती है जिसमें RHC को लोड करने वाला कोड आपका नहीं है, बल्कि आपकी इस्तेमाल की जा रही कोई लाइब्रेरी है, तो सबसे अच्छा तरीका यह है कि आप लाइब्रेरी के लेखक से संपर्क करें. उन्हें इस समस्या के बारे में बताएं. साथ ही, इसे ठीक करने के लिए कोई तरीका या कोड अपडेट करने के लिए कहें.

अगर आपको लाइब्रेरी के अपडेट का इंतज़ार नहीं करना है, तो क्या करें

कुछ लाइब्रेरी, सूचना मिलने के तुरंत बाद अपडेट भेज देंगी. हालांकि, ऐसा हो सकता है कि कुछ लाइब्रेरी को बंद कर दिया जाए या उन्हें समस्या हल करने में समय लगे. उल्लंघन के किस तरह के मामले में कार्रवाई की गई है, इसके आधार पर हो सकता है कि आपको खाते के अनब्लॉक होने और समीक्षा पूरी होने का इंतज़ार न करना पड़े. आपके पास कई विकल्प उपलब्ध हैं, ताकि आप जल्दी से काम शुरू कर सकें.

कोड की ऑडिट करना

क्या आपको पक्का पता है कि अनुरोध करने वाले कोड की ज़रूरत है? अगर इसे सिर्फ़ मिटाया जा सकता है या इसकी वजह बनने वाली लाइब्रेरी को हटाया जा सकता है, तो उस कोड को मिटा दें. इसके बाद, समस्या ठीक हो जाएगी.

क्या कोई ऐसी लाइब्रेरी है जो एक जैसी सुविधाएं देती है? npmjs.com, GitHub या अन्य साइटों पर जाकर, ऐसे अन्य विकल्प देखें जो एक जैसे इस्तेमाल के उदाहरणों को पूरा करते हों.

पेड़ हिलाना

अगर आरएचसी के उल्लंघन की वजह बनने वाले कोड का इस्तेमाल नहीं किया जा रहा है, तो टूलिंग की मदद से उसे अपने-आप मिटाया जा सकता है. webpack, Rollup, और Vite जैसे मॉडर्न बिल्ड टूल में ट्री-शेकिंग नाम की सुविधा होती है. हालांकि, इनके अलावा और भी कई मॉडर्न बिल्ड टूल उपलब्ध हैं. आपके बिल्ड सिस्टम पर चालू होने के बाद, ट्री शेकिंग को इस्तेमाल न किए गए सभी कोड पाथ हटाने चाहिए. इसका मतलब है कि आपके पास न सिर्फ़ कोड का ज़्यादा अनुपालन वाला वर्शन है, बल्कि एक बेहतर और तेज़ वर्शन भी है! यह ध्यान रखना ज़रूरी है कि सभी लाइब्रेरी को ट्री शेक नहीं किया जा सकता. हालांकि, कई लाइब्रेरी को ट्री शेक किया जा सकता है. Rollup और Vite जैसे कुछ टूल में, ट्री-शेकिंग की सुविधा डिफ़ॉल्ट रूप से चालू होती है. webpack में, इस सुविधा को चालू करने के लिए इसे कॉन्फ़िगर करना होगा. अगर एक्सटेंशन के हिस्से के तौर पर बिल्ड सिस्टम का इस्तेमाल नहीं किया जा रहा है, लेकिन कोड लाइब्रेरी का इस्तेमाल किया जा रहा है, तो हमारा सुझाव है कि आप अपने वर्कफ़्लो में बिल्ड टूल जोड़ने के बारे में सोचें. बिल्ड टूल की मदद से, ज़्यादा सुरक्षित, भरोसेमंद, और रखरखाव में आसान प्रोजेक्ट बनाए जा सकते हैं.

ट्रीशेकिंग को लागू करने का तरीका, आपके प्रोजेक्ट पर निर्भर करता है. हालांकि, 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 को सीडीएन से लाइब्रेरी Y importचाहिए, तो आपको इसे अपडेट करना होगा, ताकि यह लोकल सोर्स से लोड हो सके. मॉडर्न बिल्ड सिस्टम की मदद से, रिमोट रेफ़रंस निकालने के लिए आसानी से प्लगिन बनाए जा सकते हैं. साथ ही, उन्हें सीधे अपने कोड में इनलाइन किया जा सकता है.

इसका मतलब है कि दिया गया कोड कुछ ऐसा दिखेगा:

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

नए प्लगिन के साथ बिल्ड चलाने पर, हर रिमोट import यूआरएल का पता चल जाता है. इससे कोई फ़र्क़ नहीं पड़ता कि वह हमारा कोड था, सबडिपेंडेंसी, सबसबडिपेंडेंसी या कहीं और.

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

फ़ाइलों में मैन्युअल तरीके से बदलाव करना

सबसे आसान विकल्प यह है कि आप उस कोड को मिटा दें जिसकी वजह से आरएचसी की समस्या आ रही है. अपनी पसंद के टेक्स्ट एडिटर में खोलें और उल्लंघन करने वाली लाइनों को मिटाएं. आम तौर पर, ऐसा करने का सुझाव नहीं दिया जाता, क्योंकि यह कमज़ोर होता है और इसे भुलाया जा सकता है. अगर "library.min.js" नाम की फ़ाइल असल में library.min.js नहीं है, तो प्रोजेक्ट को मैनेज करना मुश्किल हो जाता है. RAW फ़ाइलों में बदलाव करने के बजाय, patch-package जैसे टूल का इस्तेमाल करना ज़्यादा बेहतर विकल्प है. यह एक बहुत ही बेहतरीन विकल्प है. इसकी मदद से, किसी फ़ाइल में किए गए बदलावों को सेव किया जा सकता है, न कि पूरी फ़ाइल को. इसे पैच फ़ाइलों पर बनाया गया है. ये फ़ाइलें, Git या Subversion जैसे वर्शन कंट्रोल सिस्टम को बेहतर बनाती हैं. आपको सिर्फ़ उल्लंघन करने वाले कोड में मैन्युअल तरीके से बदलाव करना होगा. इसके बाद, अंतर वाली फ़ाइल को सेव करें. साथ ही, patch-package को उन बदलावों के साथ कॉन्फ़िगर करें जिन्हें आपको लागू करना है. प्रोजेक्ट के readme पर जाकर, पूरा ट्यूटोरियल पढ़ा जा सकता है. अगर किसी प्रोजेक्ट में पैचिंग की जा रही है, तो हम आपको ज़ोर देकर यह सुझाव देते हैं कि आप प्रोजेक्ट से संपर्क करके, अपस्ट्रीम में बदलाव करने का अनुरोध करें. patch-package की मदद से, पैच को मैनेज करना बहुत आसान हो जाता है. हालांकि, पैच करने के लिए कुछ भी न होना इससे भी बेहतर है.

अगर कोड का इस्तेमाल नहीं किया जा रहा है, तो क्या करें

कोडबेस के बढ़ने पर, डिपेंडेंसी (या डिपेंडेंसी की डिपेंडेंसी या डिपेंडेंसी की…) ऐसे कोड पाथ को बनाए रख सकती हैं जिनका अब इस्तेमाल नहीं किया जा रहा है. अगर इनमें से किसी सेक्शन में, आरएचसी को लोड या एक्ज़ीक्यूट करने का कोड शामिल है, तो उसे हटाना होगा. इससे कोई फ़र्क़ नहीं पड़ता कि वह बंद है या उसका इस्तेमाल नहीं किया जा रहा है. अगर इसका इस्तेमाल नहीं किया जा रहा है, तो इसे हटा देना चाहिए. इसके लिए, ट्रीशेकिंग का इस्तेमाल किया जा सकता है या लाइब्रेरी में पैच करके इसे हटाया जा सकता है.

क्या इस समस्या को हल करने का कोई तरीका है?

आम तौर पर, नहीं. आरएचसी की अनुमति नहीं है. हालांकि, कुछ मामलों में इसकी अनुमति है. इनमें से ज़्यादातर मामलों में, किसी अन्य विकल्प का इस्तेमाल नहीं किया जा सकता.

User Scripts API

User Scripts, कोड के छोटे-छोटे स्निपेट होते हैं. इन्हें आम तौर पर उपयोगकर्ता उपलब्ध कराता है. इनका इस्तेमाल, User Script मैनेजर जैसे कि TamperMonkey और Violentmonkey के लिए किया जाता है. इन मैनेजर के लिए, उपयोगकर्ताओं के लिखे गए कोड को बंडल करना मुमकिन नहीं है. इसलिए, User Script API, उपयोगकर्ता के दिए गए कोड को एक्ज़ीक्यूट करने का तरीका बताता है. यह नहीं है, browser.scripting.executeScript या कोड एक्ज़ीक्यूट करने वाले अन्य एनवायरमेंट का विकल्प. किसी भी चीज़ को चलाने के लिए, उपयोगकर्ताओं को डेवलपर मोड चालू करना होगा. अगर Chrome Web Store की समीक्षा टीम को लगता है कि इसका इस्तेमाल, इसके मकसद के अलावा किसी और तरीके से किया जा रहा है (जैसे, उपयोगकर्ता ने कोड दिया है), तो इसे अस्वीकार किया जा सकता है. इसके अलावा, स्टोर से इसकी लिस्टिंग हटाई जा सकती है.

browser.debugger

browser.debugger एपीआई की मदद से एक्सटेंशन, Chrome Devtools Protocol के साथ इंटरैक्ट कर सकते हैं. यह वही प्रोटोकॉल है जिसका इस्तेमाल Chrome के Devtools और कई अन्य टूल के लिए किया जाता है. इसकी मदद से, कोई एक्सटेंशन रिमोट कोड का अनुरोध कर सकता है और उसे लागू कर सकता है. यह उपयोगकर्ता स्क्रिप्ट की तरह ही है. यह browser.scripting का विकल्प नहीं है. साथ ही, इससे उपयोगकर्ता को बेहतर अनुभव मिलता है. इस सुविधा का इस्तेमाल करते समय, उपयोगकर्ता को विंडो में सबसे ऊपर चेतावनी वाला बार दिखेगा. अगर बैनर को बंद कर दिया जाता है या खारिज कर दिया जाता है, तो डीबग करने का सेशन खत्म हो जाएगा.

सैंडबॉक्स किए गए iframe

अगर आपको किसी स्ट्रिंग को कोड के तौर पर देखना है और आप किसी DOM एनवायरमेंट में हैं (जैसे कि एक्सटेंशन सर्विस वर्कर के बजाय कोई कॉन्टेंट स्क्रिप्ट), तो सैंडबॉक्स किए गए iframe का इस्तेमाल किया जा सकता है. सुरक्षा को ध्यान में रखते हुए, एक्सटेंशन में डिफ़ॉल्ट रूप से eval() जैसी सुविधाएं काम नहीं करतीं. नुकसान पहुंचाने वाले कोड से, लोगों की सुरक्षा को खतरा हो सकता है. हालांकि, जब कोड को सिर्फ़ किसी भरोसेमंद एनवायरमेंट में एक्ज़ीक्यूट किया जाता है, जैसे कि iframe, तो इन जोखिमों को काफ़ी हद तक कम किया जा सकता है. iframe को वेब के बाकी हिस्सों से सैंडबॉक्स किया जाता है. इस कॉन्टेक्स्ट में, eval के इस्तेमाल को ब्लॉक करने वाली कॉन्टेंट की सुरक्षा के लिए नीति को हटाया जा सकता है. इससे आपको किसी भी मान्य JavaScript कोड को चलाने की अनुमति मिल जाती है.

अगर आपके पास कोई ऐसा इस्तेमाल का उदाहरण है जो इसमें शामिल नहीं है, तो बेझिझक टीम से संपर्क करें. इसके लिए, chromium-extensions ईमेल पाने वाले लोगों की सूची का इस्तेमाल करके सुझाव/राय दें या शिकायत करें. इसके अलावा, One Stop Support से दिशा-निर्देश पाने के लिए, नया टिकट खोलें

अगर आप फ़ैसले से सहमत नहीं हैं, तो क्या करें

नीतियों को लागू करने के लिए, बारीकी से जांच करनी पड़ती है. साथ ही, समीक्षा में मैन्युअल तरीके से इनपुट शामिल होता है. इसका मतलब है कि Chrome Web Store की टीम, कभी-कभी समीक्षा के फ़ैसले को बदलने के लिए सहमत हो सकती है. अगर आपको लगता है कि समीक्षा में कोई गलती हुई है, तो वन स्टॉप सपोर्ट का इस्तेमाल करके, अस्वीकार किए जाने के फ़ैसले के ख़िलाफ़ अपील की जा सकती है