Publish हुए extension को कोई भी unzip करके उसके अंदर का सब कुछ पढ़ सकता है। आप obfuscated extension ship कर सकते हैं या नहीं, यह store पर निर्भर करता है।
Publish हुआ extension आपके source की download की जा सकने वाली copy है
Publish हुआ extension आपके source की download की जा सकने वाली copy है। Store जो package serve करता है वह एक zip फ़ाइल है, और उसे खोलना बस एक right click है। उसके बाद background script, content scripts और कोई भी bundled logic disk पर सामान्य फ़ाइलें होती हैं। कोई भी दिलचस्प हिस्सा पढ़ सकता है, उसे उठा सकता है, और किसी दूसरे नाम से fork फिर से upload कर सकता है।
पहले store policy जाँचें
आप obfuscated extension ship कर भी सकते हैं या नहीं, यह store policy तय करती है। पाबंदियाँ हर store में अलग हैं और बदलती रहती हैं, और reviewer आपसे upload किए package के साथ पढ़ने योग्य या मूल sources जमा करने को कह सकता है। Obfuscated build ship करने से पहले अपने store की मौजूदा policy पढ़ें, और source archive माँगे जाने के लिए तैयार रहें।
Obfuscation review से build निकलवाने का, या आपका extension क्या करता है उसे reviewer से छिपाने का तरीका नहीं है। अगर store पूछे कि code क्या करता है, तो उस सवाल का जवाब दें।
Obfuscated extension build क्या बदलती है
जहाँ obfuscated build की अनुमति है, वहाँ output platform की ज़रूरतों के मुताबिक होता है। यह eval के बिना चलता है, जिसे extension की content-security-policy मना करती है।
हर build एक नया seed लेती है और अलग बनावट में निकलती है। किसी version के नामों और बनावट पर टिका fork या patch आपकी अगली publish की गई version के लिए दोबारा बनाना पड़ता है।
इसे packed output पर चलाएँ
CLI को post-build step के रूप में अपनी built output directory पर चलाएँ, या अगर आपके bundler के लिए AfterPack plugin wire किया हुआ है तो उसका उपयोग करें:
$ npx afterpack@latest dist/ --preset=hardकेवल .js, .mjs और .cjs फ़ाइलें ली जाती हैं, इसलिए manifest.json और _locales/ के अंदर की हर चीज़ अछूती निकल जाती है। जिस vendored SDK को आप अछूता छोड़ना चाहते हैं उसके लिए paths.exclude का उपयोग करें, और package में bundled node_modules/ copy तक पहुँचने के लिए paths.include का। अगर किसी symbol का नाम आपकी अपनी फ़ाइलों में एक जैसा रहना चाहिए, तो उसे identifiers.reserved से pin करें।
हर context को एक ही run में build करें, background service worker और content scripts साथ में, ताकि उनका seed एक हो और जिन message types पर दोनों तरफ़ निर्भर हैं वे आपस में मेल खाते रहें।
Zip करने से पहले package जाँचें
Build के बाद Protection Map खोलकर पक्का करें कि जिन scripts को आप protect करना चाहते थे वे कवर हुईं। Upload किए जाने वाले package के लिए sourceMap.enabled बंद रखें, क्योंकि zip के अंदर मौजूद map से source उतना ही पूरा पढ़ा जा सकता है जितना मूल फ़ाइलें ship करने पर। जिस directory को आप zip करने वाले हैं उस पर afterpack verify चलाएँ, ताकि जिस build पर protection लागू नहीं हुई वह store तक पहुँचने से पहले विफल हो जाए।
Extension के लिए यह क्या नहीं रोकता
हर release पर नया आकार किसी fork या patch को आपके extension के साथ अद्यतन रखने की लागत बढ़ाता है, और यह लागत हर बार publish करने पर फिर से चुकानी पड़ती है।
यह किसी को package पढ़ने, fork करने या फिर से upload करने से नहीं रोकता, और extension के अंदर की कोई key या token encode होने भर से सुरक्षित नहीं हो जाता। जिस API key को ship करना ही पड़े, उसका क्या करें उस स्थिति को कवर करता है।
आगे
- CLI reference: AfterPack को post-build step के रूप में चलाना।
- Quickstart: pipeline बनने से पहले पहली build।
- Shipped API keys: bundle में मौजूद credential के लिए obfuscation क्या करता है और क्या नहीं।