Electron: क्या स्रोत वास्तव में इलेक्ट्रॉन के साथ ऐप्स बनाने से सुरक्षित है?

नहीं, अपने स्रोत कोड को प्राप्त करना बहुत आसान है, भले ही आपने उन्हें asar संग्रह में पैक किया हो, V8 जावास्क्रिप्ट इंजन को कभी भी स्रोत कोड को छिपाने के लिए डिज़ाइन नहीं किया गया है। NW.js स्रोत कोड की एक फ़ाइल को पूरी तरह से छिपाने में सफल होता है, लेकिन महत्वपूर्ण प्रदर्शन डाउनग्रेड की कीमत के साथ।

इसलिए यदि आप वास्तव में अपने स्रोत कोड की सुरक्षा करना चाहते हैं, तो आपको उन्हें C++ में लिखना होगा और एक मूल नोड मॉड्यूल बनाना होगा।

कुछ विकल्प हैं, लेकिन उनके द्वारा प्रदान की जाने वाली सुरक्षा का स्तर उन कारणों से सीमित है जिनका उल्लेख

• आप C++ नोड एडऑन में अपने दम पर कुछ डिक्रिप्शन लॉजिक लागू कर सकते हैं, लेकिन यह संभवत: अभी भी टूटने योग्य होगा (उदाहरण के लिए प्रोग्राम को डिबग करें और डिक्रिप्शन के बाद स्रोत को कॉपी करें लेकिन eval से पहले)।
• EncloseJS भी है, जो आपके कोड को node.js/io.js के लिए संकलित करने का दावा करता है, इसलिए यह इलेक्ट्रॉन के साथ काम कर सकता है।
• nw.js , जो एक समान परियोजना है, में v8 स्नैपशॉट के लिए समर्थन है जो किसी प्रकार की सुरक्षा प्रदान करता है (विवरण यहां देखें)।

ध्यान दें कि इन सभी विधियों में कुछ प्रदर्शन दंड लगेगा।

@etiktin मैं इसमें भी भाग रहा हूं।
क्या सी ++ एडऑन में सीधे नोड.जेएस कोड लागू करना संभव है?

@fritx , नोड में vm नामक एक मॉड्यूल है जो कोड को
ध्यान रखें कि उपयोगकर्ता अभी भी डेवलपर टूल खोलने और लोड की गई स्क्रिप्ट को देखने का प्रबंधन कर सकता है। यहां तक ​​​​कि अगर आप कस्टम इलेक्ट्रॉन बिल्ड का उपयोग करके इसे ब्लॉक करने का प्रबंधन करते हैं और यह देखने के लिए कि आपके इलेक्ट्रॉन बिल्ड के साथ छेड़छाड़ नहीं की गई है, तब भी उपयोगकर्ता आपके कोड को मेमोरी में एक स्ट्रिंग के रूप में देख सकता है।

अच्छा लगता है स्रोत की रक्षा करें! :चाभी:

फिर मेरे पास एक सवाल है, GitKraken, Whatsapp या Slack जैसे बंद कोड इलेक्ट्रॉन ऐप कोड को कैसे छिपा सकते हैं?

@ alexis57 मेरा एक ही सवाल है; शायद यह सिर्फ इतना है कि निरीक्षण तत्व अक्षम है या कुछ और

या हो सकता है कि मुख्य कोड सी/सी ++ लाइब्रेरी से आता है और फिर वे केवल जीयूआई के लिए इलेक्ट्रॉन का उपयोग करते हैं, पता नहीं ...

जानना चाहेंगे कि व्हाट्सएप और स्लैक अपने सोर्स कोड को भी कैसे सुरक्षित रखते हैं

AFAIK यह बस असुरक्षित है। आप उनका app.asar निकाल सकते हैं और सोर्स कोड एक्सेस कर सकते हैं। एप्लिकेशन के संवेदनशील हिस्सों के लिए आप आमतौर पर C/C++ जैसी संकलित भाषा में कस्टम ऐडऑन लिखते हैं, जैसा कि ऊपर बताया गया है।

हम इसमें c++ code कैसे कंपाइल कर सकते हैं?

देखें: https://nodejs.org/api/addons.html

@boeserwolf धन्यवाद! :)

सदस्यता लिया

यह node-ffi साथ भी संभव है। इलेक्ट्रॉन का उपयोग केवल UI के लिए किया जाना चाहिए।

सी/सी ++ में कोड लिखने और फिर इसे वेब असेंबली में बदलने के लिए emscripten जैसे टूल का उपयोग करने की उचित हो सकता है। यह क्रोमियम के साथ बढ़िया काम करना चाहिए

पर्याप्त प्रयास से किसी भी चीज को अलग किया जा सकता है/अस्पष्ट किया जा सकता है। जावास्क्रिप्ट में अपना कोड लिखना और इसे एएसएआर में शामिल करने से अधिकांश लोग बाहर रहेंगे। क्या उस कोड को सुरक्षित रखने का कोई कारण है जिसमें कॉपीराइट/लाइसेंस शामिल नहीं है?

मेरे 2 सेंट यहाँ, NW v8 स्नैपशॉट की समस्या को हल करते प्रतीत होते हैं
https://nwjs.io/blog/js-src-protect-perf/

मैं nwjs से इस लेख में आया, "संकलित बाइनरी कोड अब बिना प्रदर्शन ओवरहेड के जेएस स्रोत कोड के रूप में तेजी से चलता है" जो पहले 30% था, और इसे एनडब्ल्यू के बाद के रिलीज में डिफ़ॉल्ट रूप से चालू किया जाएगा।

वास्तव में इसमें दिलचस्पी है, मैंने @craftpip द्वारा हमें

यह डेवलपर्स के लिए बहुत असुविधाजनक है। छोड़ दें और NW पर स्विच करें ...

मैं अन्य नोड.जेएस प्रोजेक्ट साझा करना चाहता हूं जो बहुत ही सुंदर तरीके से कोड सुरक्षा का उपयोग करते हैं: https://github.com/zeit/pkg

हो सकता है कि इलेक्ट्रॉन में स्रोत सुरक्षा की आशा हो?

कुछ हिस्सों के लिए C++ का उपयोग करने के अलावा, आप अपने JavaScript स्रोत को छोटा और _obfuscate_ भी कर सकते हैं (उदाहरण के लिए Javascript -obfuscator का उपयोग करके)।

लघुकरण और आपत्ति एक साथ _dramatically_ आपके कोड को "चोरी" करने के लिए आवश्यक प्रयास (और इस प्रकार _cost_) को बढ़ाएंगे, अक्सर इस बिंदु तक कि खरोंच से आपके पूरे एप्लिकेशन को रिवर्स-इंजीनियरिंग आसानी से अधिक संभव हो जाता है - और तकनीकी रूप से ऐसा कुछ भी नहीं है जो आप कर सकते हैं रिवर्स-इंजीनियरिंग के बारे में करें, भले ही आप पूर्ण-देशी हों (कानून की तलाश के अलावा कुछ भी नहीं)।

यदि आप अपने स्रोत कोड को छिपाने के बारे में चिंतित नहीं हैं, लेकिन आप अपने रहस्यों को छिपाना चाहते हैं जैसे:

• OAuth क्रेडेंशियल
• यूआरएल जनता के लिए ज्ञात नहीं है (यानी निजी बैकएंड एपीआई एंडपॉइंट्स)
• बाकी एपीआई क्रेडेंशियल
• कोई भी कुंजी और रहस्य
• पासवर्डों

मैंने इस समस्या के समाधान के लिए एक मुफ़्त सेवा बनाई है। मुझे इसे बनाना पड़ा क्योंकि मैं एक वाणिज्यिक इलेक्ट्रॉन ऐप बना रहा था और मेरी साख चोरी होने के बारे में चिंतित था।

यह एक क्रॉस-प्लेटफ़ॉर्म हेल्पर एप्लिकेशन बनाकर काम करता है जो आपके वास्तविक इलेक्ट्रॉन एप्लिकेशन को लॉन्च करता है यदि आपके एप्लिकेशन के साथ छेड़छाड़ नहीं की गई है। एक बार जब यह एप्लिकेशन लॉन्च करता है, तो यह आपके क्रेडेंशियल्स को पर्यावरण चर के माध्यम से पारित कर देगा।

अधिक जानकारी:

परिचय:
https://medium.com/@rocketlaunchr.cloud/introducing -electron-vault-d09ade2c2020

दस्तावेज़ीकरण:
https://rocketlaunchr.github.io/electron-vault-docs/

@ जॉन वीज़

If the data is indeed sensitive, I think it should be handled by a remote server.

रिमोट सर्वर सर्वर वास्तव में कैसे जानता है कि क्लाइंट वास्तव में आपका अपरिवर्तित इलेक्ट्रॉन ऐप है?
यही वह समस्या है जिसे मैं हल करने की कोशिश कर रहा था।

यदि आप Client Credentials अनुदान प्रकार के साथ OAuth का उपयोग करते हैं, तो आपका client_secret अभी भी आपके आवेदन में बेक किया हुआ है और सिद्धांत रूप में कोई भी इसे पढ़ सकता है। इलेक्ट्रॉन स्रोत कोड 100% खुला और उपलब्ध होने के साथ, "दिलचस्प" दिखने वाले स्ट्रिंग्स को खोजना आसान है।

समस्या को हल करने का कोई 100% मूर्खतापूर्ण तरीका नहीं है, लेकिन मेरा मानना ​​​​है कि मेरा समाधान एक निश्चित सुधार है।

मेरा मानना ​​​​है कि यह आपके जेएस ऐप्स को वेबपैक या एसपीए ढांचे जैसे कोणीय 2/4/6 या वीयूजेएस 2 के साथ बनाकर संभव है। यह आपके कोड और इसके श्रमसाध्य को छोटा करता है, भले ही कोई असर फ़ाइल निकालता है, लेकिन उनके लिए आपका कोड पढ़ना मुश्किल हो सकता है

मुझे लगता है कि इस मुद्दे को केवल वास्तविक एन्क्रिप्शन पर ध्यान केंद्रित नहीं करना चाहिए। लेकिन इस तथ्य पर कि किसी अन्य एप्लिकेशन/उपयोगकर्ता ने क्लाइंट के सोर्स कोड के साथ छेड़छाड़ नहीं की है।

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

@tulpn

चूंकि अखंडता जांच को इलेक्ट्रॉन बाइनरी में ही एकीकृत किया जा सकता है, इसलिए कोई...

- तो यह पहले से ही केवल अखंडता-जांच या एन्क्रिप्शन/डिक्रिप्शन इलेक्ट्रॉन निकालने का मामला है, और आपके पास स्रोत कोड है। मुझे विश्वास है कि obfuscation एकमात्र दृष्टिकोण है जिसे आप यहां ले सकते हैं (चाहे वह minification, minification + obfuscation, या मूल कोड संकलन हो)।

वह, या आपके कुछ ऐप कोड को दूरस्थ सेवा में ले जाना (प्रमाणीकरण के साथ यदि आपको सुरक्षा की आवश्यकता है)।

आप अपने डेटा को एन्क्रिप्ट कर सकते हैं और इसे रनटाइम पर डिक्रिप्ट कर सकते हैं और इसे सीधे टोकन या किसी भी प्रकार के संवेदनशील डेटा जैसे चर में लोड कर सकते हैं, लेकिन यदि आप संपूर्ण जावास्क्रिप्ट फ़ाइलों को एन्क्रिप्ट करने की बात कर रहे हैं तो यह प्रदर्शन पर एक टोल लेगा। आप Node C++ Addons को एक शॉट दे सकते हैं

जैसा कि नोडज कहते हैं:

Node.js Addons गतिशील रूप से जुड़े साझा ऑब्जेक्ट हैं, जो C++ में लिखे गए हैं, जिन्हें आवश्यकता () फ़ंक्शन का उपयोग करके Node.js में लोड किया जा सकता है, और जैसे कि वे एक सामान्य Node.js मॉड्यूल थे। इनका उपयोग मुख्य रूप से Node.js और C/C++ पुस्तकालयों में चल रहे जावास्क्रिप्ट के बीच एक इंटरफ़ेस प्रदान करने के लिए किया जाता है।

मूल रूप से यह आपके कोड को बाइनरी में संकलित करता है और इस तरह आप अपने कोड को सार कर सकते हैं और प्रदर्शन बहुत तेज हो जाएगा और आप कुछ हद तक अपना कोड छुपा सकते हैं।

नहीं, अपने स्रोत कोड को प्राप्त करना बहुत आसान है, भले ही आपने उन्हें asar संग्रह में पैक किया हो, V8 जावास्क्रिप्ट इंजन को कभी भी स्रोत कोड को छिपाने के लिए डिज़ाइन नहीं किया गया है। NW.js स्रोत कोड की एक फ़ाइल को पूरी तरह से छिपाने में सफल होता है, लेकिन महत्वपूर्ण प्रदर्शन डाउनग्रेड की कीमत के साथ।

इसलिए यदि आप वास्तव में अपने स्रोत कोड की सुरक्षा करना चाहते हैं, तो आपको उन्हें C++ में लिखना होगा और एक मूल नोड मॉड्यूल बनाना होगा।

मैं c++ addons से devtools को कैसे अक्षम कर सकता हूं और मैं c++ addons से इलेक्ट्रॉन के सभी API तक कैसे पहुंच सकता हूं और क्या devtool के बिना ऐप को पैकेज करने की कोई योजना है, यह हैक्स को रोकने और एप्लिकेशन के कम आकार के साथ मददगार हो सकता है ( @ जेडसीबेंज़ )

हम सभी अपने सोर्सकोड से थक चुके हैं प्रकाशित हो जाते हैं। मैं nw . में जा रहा हूँ

@ahmtcn123 आपकी टिप्पणी इस समस्या को हल करने में कैसे मदद कर रही है?

आप वेब तकनीक के साथ ऐसे ऐप्स बनाना चाहते हैं जिनका सार उनके स्रोत कोड सार्वजनिक हो, इसलिए उस रवैये के साथ रुकें।

• आप इस समस्या के समाधान के लिए इलेक्ट्रॉन में योगदान कर सकते हैं
• C++ मॉड्यूल लिखें
• अपने कोड को छोटा/बाधित/प्रबंधित करें (और स्रोत मानचित्रों को अक्षम करना न भूलें)
• आप किसी अन्य समान तकनीक (जैसे nw.js) में जा सकते हैं, या आप देशी जा सकते हैं
• कुछ अन्य समाधान यहां साझा किए गए हैं, आप प्रदर्शन के लिए अस्पष्टता का व्यापार कर सकते हैं (जो कि एक स्पष्ट विकल्प नहीं है जब हम पहले से ही इलेक्ट्रॉन के प्रदर्शन/संसाधन खपत को जानते हैं)

चीयर्स!

_संपादित करें: वोट कम करते रहें दोस्तों_

v8snapshot का समर्थन क्यों नहीं करते?

मैं समझता हूं कि हम सोर्स कोड की पूरी तरह से रक्षा नहीं कर सकते। लेकिन दूसरा तरीका लॉजिक कोड की सुरक्षा के लिए देशी संकलित तकनीक (जैसे गोलांग) का उपयोग करके वेब सेवा बनाना और स्थानीयहोस्ट के माध्यम से इलेक्ट्रॉन यूआई से कॉल करना हो सकता है।

आख़िरी शब्द

एनडब्ल्यू

यह मुद्दा क्यों बंद किया गया?

क्योंकि स्रोत कोड को छिपाना हमेशा एक विवादास्पद विषय रहा है क्योंकि इसे अस्पष्टता के माध्यम से सुरक्षा आपके कोड की सुरक्षा के लिए एक बहुत ही खराब तरीका माना जाता है।

यदि आप कुछ सुरक्षा चाहते हैं, तो अधिक मानक विधियों का उपयोग करें, जैसे महत्वपूर्ण कार्यों को करने के लिए प्रमाणीकरण, एन्क्रिप्शन, आदि।

ईमानदारी से, आप सी पर अपना ऐप लिख सकते हैं और बाइनरी वितरित कर सकते हैं, वैसे भी हमें आपका स्रोत कोड मिल जाएगा।

पीडी: आप बड़े लड़कों (व्हाट्सएप वेब, स्लैक, टीम, बनाम कोड) के स्रोत कोड तक पहुंच सकते हैं और उनमें से कोई भी इसकी परवाह नहीं करता है, शायद आप कुछ गलत कर रहे हैं।

"" "पीडी: आप बड़े लड़कों (व्हाट्सएप वेब, स्लैक, टीम, बनाम कोड) के स्रोत कोड तक पहुंच सकते हैं और उनमें से कोई भी इसकी परवाह नहीं करता है, शायद आप कुछ गलत कर रहे हैं।" ""

शायद ही कोई मूर्खतापूर्ण तर्क दे सकता है।

सॉफ़्टवेयर को रिवर्स इंजीनियर किए बिना बेचना और उन तरीकों से उपयोग करना जो असामान्य नहीं माना जाता है, वास्तव में इसके लिए बिल्कुल कानून हैं, जो उपयोगकर्ताओं को अभी भी ऐसा करने से नहीं रोकता है।

@kidandcat

ईमानदारी से, आप सी पर अपना ऐप लिख सकते हैं और बाइनरी वितरित कर सकते हैं, वैसे भी हमें आपका स्रोत कोड मिल जाएगा।

आगे बढ़ें, माइक्रोसॉफ्ट वर्ड, फोटोशॉप, या यहां तक ​​कि टॉप सेलिंग गेम्स जैसे सभी शीर्ष बिकने वाले ऐप्स का स्रोत प्राप्त करें। क्या आप अरबपति हैं और मैं इससे अनजान हूं या क्या?

नहीं, मैं अरबपति नहीं हूं क्योंकि उन कार्यक्रमों का स्रोत कोड बेकार है, आप इसके साथ क्या करने जा रहे हैं?

दोस्तों कृपया, इस सूत्र में बहुत सारे लोग हैं जिन्हें प्रत्येक टिप्पणी के लिए सूचित किया जाता है, कृपया इसे रचनात्मक रखें।

संभावित रूप से संक्षेप में, मेरी राय में, जावास्क्रिप्ट की स्रोत-कोड विशिष्टताओं से निपटने के लिए कई मामलों में सौदा-ब्रेकर क्यों नहीं है:

• यहां सूचीबद्ध बहुत से उदाहरण ऐप्स/सेवाएं मुख्य रूप से उनके _कर्षण_ द्वारा संचालित हैं; उदाहरण के लिए ट्विटर को लें, यह वास्तव में एक रहस्य नहीं है कि यह आंतरिक रूप से कैसे काम कर रहा है, लेकिन यहां तक ​​​​कि इसे पूरी तरह से कॉपी करके और इसे पूरी तरह से पुन: पेश करने से आपको ट्रैफ़िक, विज्ञापन, ब्रांड, बैकिंग इंफ्रास्ट्रक्चर के बिना कहीं भी नहीं मिलेगा। आदि।
• उचित अस्पष्टता किसी भी अर्थपूर्ण तरीके से स्रोत कोड तक पहुंचना अत्यंत, _निषेधात्मक रूप से_ कठिन बना देती है, उस बिंदु तक जहां एप्लिकेशन के व्यवहार का निरीक्षण करना और मूल पर भरोसा किए बिना, उसके आधार पर इसे रिवर्स-इंजीनियर करना अधिक संभव हो जाता है। स्रोत कोड -- जैसे C++ . के मामले में बहुत कुछ
• कॉपीराइट कानून द्वारा संरक्षित किसी एप्लिकेशन से विचारों और/या समाधानों को चुराना एक कानूनी प्रश्न है, तकनीकी नहीं है, और इस तरह, कार्यान्वयन की रक्षा करना एक कानूनी मामला है, चाहे लागू किए गए सुरक्षा के स्तर की परवाह किए बिना; एक गड़बड़ चीनी फर्म आपके लोगो और ऐप को बिना किसी समस्या के चुरा लेगी, भले ही वह जावास्क्रिप्ट या असेंबली में लिखा गया हो
• इसके अतिरिक्त, यदि आप अस्पष्टता के बारे में आश्वस्त नहीं हैं, तो आप अपने आवेदन में सी ++ कोड शामिल कर सकते हैं, या आप कोड को दूरस्थ सेवा में ले जा सकते हैं, जो कि बाकी सब कुछ (सी ++ समेत) के विपरीत, प्रत्यक्ष निरीक्षण से पूरी तरह से सुरक्षित है (रिवर्स-इंजीनियरिंग से नहीं) हालांकि)

@JohnWeisz ने वास्तव में बहुत समझदार बातें कही हैं। मैं यह भी जोड़ूंगा कि यदि यह आपके लिए पर्याप्त नहीं है, तो आप आज WebAssembly का उपयोग कर सकते हैं। स्रोत कोड की सुरक्षा के मामले में, यह काफी अच्छा होना चाहिए।

https://developer.mozilla.org/en-US/docs/WebAssembly

@kidandcat क्या यह सच है?" ईमानदारी से, आप सी पर अपना ऐप लिख सकते हैं और बाइनरी वितरित कर सकते हैं, हमें आपका स्रोत कोड वैसे भी मिल जाएगा।"

मैंने Google पर खोज की, ऐसा लगता है कि सी/सी ++ से संकलित बाइनरी से स्रोत कोड प्राप्त करना असंभव है। अधिक से अधिक, हम असेंबली स्टेटमेंट प्राप्त कर सकते हैं।

मैं एक वाणिज्यिक विंडोज़ डेस्कटॉप सॉफ्टवेयर विकसित कर रहा हूँ। कोड तर्क प्रमुख क्षमता है। इन तर्कों को क्लाइंट साइड पर चलाना है लेकिन मैं नहीं चाहता कि मेरे प्रतियोगी इसे प्राप्त करें। तो मेरे मामले में कोड सुरक्षा डील ब्रेकर है।

@z1988hf

ऐसा लगता है कि सी/सी ++ से संकलित बाइनरी से स्रोत कोड प्राप्त करना असंभव है। अधिक से अधिक, हम असेंबली स्टेटमेंट प्राप्त कर सकते हैं

इसका वास्तव में मतलब यह है कि आप मूल स्रोत कोड, या कुछ समकक्ष को बहुत अधिक रिवर्स-इंजीनियर कर सकते हैं, केवल यह आमतौर पर निषिद्ध रूप से कठिन होता है और इस प्रकार महंगा होता है। अस्पष्ट कोड के बारे में भी यही कहा जा सकता है।

@kidandcat क्या यह सच है?" ईमानदारी से, आप सी पर अपना ऐप लिख सकते हैं और बाइनरी वितरित कर सकते हैं, हमें आपका स्रोत कोड वैसे भी मिल जाएगा।"

मैंने Google पर खोज की, ऐसा लगता है कि सी/सी ++ से संकलित बाइनरी से स्रोत कोड प्राप्त करना असंभव है। अधिक से अधिक, हम असेंबली स्टेटमेंट प्राप्त कर सकते हैं।

मैं एक वाणिज्यिक विंडोज़ डेस्कटॉप सॉफ्टवेयर विकसित कर रहा हूँ। कोड तर्क प्रमुख क्षमता है। इन तर्कों को क्लाइंट साइड पर चलाना है लेकिन मैं नहीं चाहता कि मेरे प्रतियोगी इसे प्राप्त करें। तो मेरे मामले में कोड सुरक्षा डील ब्रेकर है।

साथ ही असेंबली कोड मेट है, आपका लॉजिक होगा। आपको अपने कोड को केवल संकलित करने की तुलना में सुरक्षित रखने के लिए और अधिक काम करने की आवश्यकता होगी। (लेकिन जैसा कि @JohnWeisz ने कहा, रिवर्स इंजीनियरिंग सॉफ्टवेयर बहुत महंगा है, इसलिए आपको चिंता करने की आवश्यकता नहीं होगी यदि आपके प्रतिस्पर्धियों को इसे आज़माने के लिए कुछ हज़ार डॉलर फेंकने में कोई दिलचस्पी नहीं है)

उन लोगों के लिए जो स्लैक जैसे ऐप्स को स्रोत कोड सुरक्षा की परवाह नहीं कर रहे हैं, यह सभी ऐप्स के लिए सबसे अच्छी तुलना नहीं है। स्लैक एक ऐसी सेवा है जो ऑनलाइन रहती है और उनका इलेक्ट्रॉन ऐप उनके वेब ऐप को प्रदर्शित करने के लिए सिर्फ एक शेल है। स्लैक जैसे ऐप्स के अधिकांश गुप्त सॉस वेब सर्वर पर रहते हैं।

उन लोगों के लिए जो स्लैक जैसे ऐप्स को स्रोत कोड सुरक्षा की परवाह नहीं कर रहे हैं, यह सभी ऐप्स के लिए सबसे अच्छी तुलना नहीं है। स्लैक एक ऐसी सेवा है जो ऑनलाइन रहती है और उनका इलेक्ट्रॉन ऐप उनके वेब ऐप को प्रदर्शित करने के लिए सिर्फ एक शेल है। स्लैक जैसे ऐप्स के अधिकांश गुप्त सॉस वेब सर्वर पर रहते हैं।

@अापका खास
कैसे Spotify के बारे में !!!, हम जानते हैं कि आपका क्या मतलब है लेकिन ऑफ़लाइन ऐप्स के बारे में कैसे ??

@annymosse Spotify की गुप्त चटनी उनका ऐप नहीं है। अगर किसी ने Spotify ऐप के स्रोत को चुरा लिया है, तो इससे कोई फर्क नहीं पड़ेगा। ऐप काफी अच्छा है। लोग Spotify के लिए उपयोग और भुगतान करने का वास्तविक कारण सामग्री की पेशकश और स्ट्रीमिंग संगीत की सुविधा के कारण है। कुछ UX विवरण हैं जो संभवतः Spotify के कई ग्राहकों द्वारा विकल्पों के लिए पसंद किए जाते हैं, लेकिन प्रतियोगियों को इसे कॉपी करने के लिए वास्तव में स्रोत कोड की आवश्यकता नहीं होती है। इसके अतिरिक्त, मैंने Spotify के स्रोत कोड को देखने का प्रयास नहीं किया है, लेकिन मुझे लगता है कि उनके पास कहीं न कहीं ऐप में किसी प्रकार की सुरक्षा है। संभावित रूप से कुछ ठोस आपत्ति के साथ-साथ देशी सी एडऑन भी। मुझे लगता है कि डीआरएम के कारण उनके लिए यह एक आवश्यकता होगी।

@yourfavorite बस उन्हें स्रोत पर एक नज़र डालें, अपने दिमाग में रखें कभी-कभी हम वाणिज्यिक ऐप्स के लिए हमारे स्रोत को asar files और package.json और *.js पास करने के लिए कुछ विधि

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

और स्पष्ट होने के लिए, मैं इलेक्ट्रॉन में आने वाले किसी प्रकार के स्रोत कोड संरक्षण के पक्ष में हूं।

मुझे स्रोत कोड सुरक्षा की आवश्यकता है। मुझे यहां एक उपयोग केस प्रदान करने दें:

मैं Google अनुवाद API पर एक अनुवाद सॉफ़्टवेयर आधार बनाने का प्रयास कर रहा हूं

उपयोगकर्ता सॉफ़्टवेयर में एक .srt/.ass उपशीर्षक फ़ाइल खींचें, और सॉफ़्टवेयर प्रत्येक पंक्ति का अनुवाद करने के लिए Google अनुवाद API का उपयोग करेगा।

उदाहरण

उपयोगकर्ता ने 1 वीडियो और 1 अंग्रेजी उपशीर्षक डाउनलोड किया।
अब वे इस सॉफ़्टवेयर का उपयोग इस अंग्रेज़ी उपशीर्षक का अनुवाद करने के लिए कर सकते हैं
चीनी या किसी अन्य भाषा में।
तो वे सामग्री को समझ सकते हैं।

संकट

यदि स्रोत कोड प्राप्त करना आसान है।
जाहिरा तौर पर हमलावर मेरी एपीआई कुंजी और रहस्य प्राप्त कर सकता है। और इसका दुरुपयोग करें।
और मुझे Google से भारी बिल मिलेगा ($500? $1000? अधिक?)

त्वरित अपडेट (2020-मार्च-29)

मैं इलेक्ट्रॉन.जेएस के साथ Vue.js + Webpack का उपयोग कर रहा हूं
तो सभी कोड छोटा हो जाएगा, इसलिए अब कोई समस्या नहीं है

@ 1c7

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

@lvkins ओह मैं देखता हूँ। मुझे नहीं पता था कि सी ++ सॉफ्टवेयर में भी यह समस्या है। मैं इस भाषा से परिचित नहीं हूं।
सुझावों के लिए धन्यवाद!

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

@lvkins आप मुझे सही जवाब दे रहे हैं?
सलाह के लिये धन्यवाद। मैं इसकी जांच कराऊंगा।

मैं Electron.js का उपयोग करना चाहता हूं क्योंकि मैं चाहता हूं कि यह अनुवाद सॉफ्टवेयर मैक और विंडोज दोनों पर चल सके।

ऐसा लगता है कि Electron.js + कुछ C++ मेरी एपीआई कुंजी की रक्षा कर सकता है&गुप्त

धन्यवाद @lvkins

@ 1c7 वास्तव में

यहां से शुरू करें: https://nodejs.org/api/addons.html

यदि इलेक्ट्रान की सुरक्षा की पूर्ण कमी आपको चिंतित करती है, तो आप NW.js को भी आजमा सकते हैं।

आपको कामयाबी मिले!

@ 1c7 और लिनक्स क्यों नहीं? !! मुझे लगता है कि यह सभी प्लेटफार्मों के लिए समान कोड-बेस है ??!

@annymosse मैं सिर्फ लिनक्स का उल्लेख करना भूल गया, लिनक्स के खिलाफ कुछ भी नहीं।

एफवाईआई:

• मैं मैकबुक प्रो 2017 15 इंच (मैक) का उपयोग कर रहा हूं
• मेरे अधिकांश उपयोगकर्ता विंडोज़ (विंडोज़) का उपयोग करते हैं
• मैंने अपने किसी सॉफ़्टवेयर उपयोगकर्ता को Linux (Linux) पर इसका उपयोग करते नहीं देखा है

मैं https://github.com/1c7/Translate-Subtitle-File को चालू करने के बारे में सोच रहा था
इस परियोजना को एक गंभीर परियोजना में (पैसा चार्ज करें और उच्च गुणवत्ता रखें (इस पर अधिक समय व्यतीत करें))
इसलिए मैं अभी अपना शोध कर रहा हूं

यह उपकरण अभी के लिए ज्यादातर चीन के बाजार को लक्षित करेगा। (सभी बटन और टेक्स्ट चीनी में होंगे)
i18n मानचित्र पर है लेकिन जल्द ही नहीं होने वाला है

मेरे पास i18n और यांडेक्स अनुवादक एपीआई बनाने की योजना थी, लेकिन उसी समस्या के कारण मैंने परियोजना को रद्द कर दिया, फिर लिनक्स पर अधिकांश नए उपयोगकर्ताओं को उन कार्यक्रमों का विश्वास नहीं है जो उन्हें लगता है कि यह लिनक्स में मौजूद नहीं है या कोई विकल्प नहीं है इसलिए यदि आप वह प्रोजेक्ट बनाते हैं और आपके उपयोगकर्ता लक्ष्य केवल मीडिया का अनुवाद करते हैं तो वे किसी भी लिनक्स डिस्टो या मेरे पसंदीदा डिस्ट्रीब्यूशन डीपिन (चीनी लिनक्स डिस्ट्रो) का उपयोग कर सकते हैं, आशा है कि आपके और सभी लिनक्स उपयोगकर्ताओं के लिए सबसे अच्छा होगा।

आपकी API कुंजियां और रहस्य कभी भी प्रकाशित ऐप्लिकेशन में नहीं होने चाहिए. इसके बजाय है
उन्हें अपने एपीआई/बैकएंड पर, abd किसी प्रकार के साथ उनकी रक्षा करें
प्रमाणीकरण / थ्रॉटलिंग। फिर क्या आपका ऐप आपके एपीआई का उपभोग करता है।

एम डोम, 20 डे आउट डे 2019 10:22, चेंग झेंग नोटिफिकेशन @github.com
एस्क्रेव्यू:

@annymosse https://github.com/annymosse मैं सिर्फ लिनक्स का उल्लेख करना भूल गया,
लिनक्स के खिलाफ कुछ भी नहीं

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/electron/electron/issues/2570?email_source=notifications&email_token=ADCOXMFCSHRX3PZTE7GHKDTQPRLQRA5CNFSM4BODX2F2YY3PNVWWK3TUL52HS4DFVREXGEB43VMVBW63LNMVXH2GOTIKTN
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ADCOXMCKPUOMQPM3JKZP5J3QPRLQRANCNFSM4BODX2FQ
.

बाइटनोड नामक एक पुस्तकालय है जो आपको अपनी जावास्क्रिप्ट फाइलों को बाइनरी फाइलों में बदलने की अनुमति देता है ताकि कोई भी इसे पढ़ न सके।

पहले अपने सर्वर पर और अपने फ़ोल्डर में बाइटनोड स्थापित करें:

>npm i -g bytenode
>npm i bytenode

इसमें निम्न कोड के साथ एक सामान्य नोडजेएस फ़ाइल बनाएं। आइए कल्पना करें कि हम निम्नलिखित कोड को नाम देते हैं: ok.js

>console.log('bytenode works!);
फिर, अपना जावास्क्रिप्ट कोड संकलित करें। कमांड आपकी फ़ाइल के समान नाम वाली एक .JSC फ़ाइल बनाएगी।

user<strong i="15">@machine</strong>:~$ bytenode -c ok.js
फिर, एक मुख्य इलेक्ट्रॉन JS फ़ाइल में, आप अपने बाइनरी को कॉल करेंगे, चलिए इसे test.js कहते हैं:

const bytenode = require('bytenode'); 
const myFile=require('./ok.jsc'); 
myFile;

बचाओ।

फिर, आप test.js: node test.js को टेस्ट करने के लिए कॉल करेंगे। यह देखने के लिए "cat ok.jsc" करें कि यह वास्तव में एक बाइनरी है और कोई भी आपका कोड नहीं देख सकता है। आप अपनी मूल सादा परीक्षण जेएस फ़ाइल को किसी अन्य स्थान पर ले जा सकते हैं।
मैंने इलेक्ट्रॉन से इसका परीक्षण नहीं किया, लेकिन मुझे लगता है कि यह काम करेगा, है ना?