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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ट्री शेकिंग

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

ट्रीशेकिंग को लागू करने का तरीका, आपके प्रोजेक्ट पर निर्भर करता है. हालांकि, Rollup का एक आसान उदाहरण देखें. इसमें, अपने प्रोजेक्ट कोड को कंपाइल करके, ट्रीशेकिंग की सुविधा जोड़ी जा सकती है. उदाहरण के लिए, अगर आपके पास main.js नाम की कोई फ़ाइल है, जो सिर्फ़ Firebase Auth में लॉग इन करती है, तो:

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 नाम की एक ही फ़ाइल में कंपाइल किया गया होगा.

Rollup का इस्तेमाल करना आसान है. हालांकि, इसे बहुत ज़्यादा कॉन्फ़िगर किया जा सकता है. इसमें हर तरह का मुश्किल लॉजिक और कॉन्फ़िगरेशन जोड़ा जा सकता है. इसके लिए, इसका दस्तावेज़ देखें. इस तरह के बिल्ड टूल जोड़ने से, कोड छोटा और ज़्यादा कारगर होगा. साथ ही, इस मामले में, रिमोटली होस्टेड कोड की समस्या ठीक हो जाएगी.

फ़ाइलों में अपने-आप बदलाव होना

रिमोटली होस्टेड कोड, आपके कोडबेस में एक और तरीके से आ सकता है. यह तरीका है, आपके शामिल की जा रही किसी लाइब्रेरी की सबडिपेंडेंसी के तौर पर. अगर लाइब्रेरी X, सीडीएन से लाइब्रेरी Y को import करना चाहती है, तो आपको इसे अपडेट करना होगा, ताकि यह लोकल सोर्स से लोड हो सके. आधुनिक बिल्ड सिस्टम की मदद से, प्लग इन आसानी से बनाए जा सकते हैं. इनकी मदद से, रिमोट रेफ़रंस को एक्सट्रैक्ट किया जा सकता है और सीधे आपके कोड में इनलाइन किया जा सकता है.

इसका मतलब है कि अगर कोड ऐसा दिखता है, तो:

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 यूआरएल की पहचान की जाती है. भले ही, वह हमारा कोड हो, सबडिपेंडेंसी हो, सबसबडिपेंडेंसी हो या कहीं और मौजूद हो.

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

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

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

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

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

क्या कोई दूसरा तरीका है?

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

User Scripts API

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

chrome.debugger

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

सैंडबॉक्स वाले iframe

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

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

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

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