Electron: هل المصدر محمي حقًا بإنشاء تطبيقات باستخدام Electron؟

لا ، من السهل جدًا الحصول على شفرة المصدر الخاصة بك حتى عندما تقوم بتعبئتها في أرشيف asar ، لم يتم تصميم محرك V8 JavaScript مطلقًا لإخفاء شفرة المصدر. نجح NW.js في إخفاء ملف واحد من الكود المصدري تمامًا ، ولكن مع خفض سعر الأداء الملحوظ.

لذلك ، إذا كنت تريد حقًا حماية شفرة المصدر الخاصة بك ، فيجب عليك كتابتها بلغة C ++ وإنشاء وحدة Node module أصلية.

هناك بعض الخيارات ، لكن مستوى الحماية الذي يقدمونه محدود بسبب الأسباب التي ذكرتها zcbenz :

• يمكنك تنفيذ بعض منطق فك التشفير بنفسك ، في ملحق عقدة C ++ ، ولكن من المحتمل أن يظل قابلاً للكسر (مثل تصحيح أخطاء البرنامج ونسخ المصدر بعد فك التشفير ولكن قبل EVAL).
• هناك أيضًا EncloseJS ، الذي يدعي أنه يجمع الكود الخاص بك لـ node.js / io.js ، لذلك قد يعمل مع Electron.
• nw.js ، وهو مشروع مشابه ، يدعم لقطات v8 التي توفر نوعًا من الحماية (انظر التفاصيل هنا ).

لاحظ أن كل هذه الأساليب ، ستتحمل بعض عقوبة الأداء.

etiktin أنا أواجه هذا أيضًا.
هل من الممكن فقط تطبيق كود node.js في الملحق C ++ مباشرة؟

fritx ، لدى Node وحدة نمطية تسمى vm يمكنها تقييم الكود. أعتقد أنه يمكنك العثور على طريقة لاستدعائها أو أنها تبرز واجهة برمجة تطبيقات C ++ من الملحق الخاص بك وتستخدمها لتحميل التعليمات البرمجية الخاصة بك.
ضع في اعتبارك أنه لا يزال بإمكان المستخدم إدارة فتح أدوات المطور ومشاهدة النص الذي تم تحميله. حتى إذا تمكنت من حظر ذلك باستخدام بنية إلكترونية مخصصة والتحقق من الملحق لمعرفة أن بناء Electron الخاص بك لم يتم العبث به ، فلا يزال بإمكان المستخدم رؤية الكود الخاص بك كسلسلة في الذاكرة.

يبدو جيدا حماية المصدر! :مفتاح:

ثم لدي سؤال ، كيف يمكن لتطبيقات الإلكترون المغلقة مثل GitKraken أو Whatsapp أو Slack إخفاء الكود؟

@ alexis57 لدي نفس السؤال ؛ ربما يكون الأمر مجرد أن عنصر الفحص معطل أو شيء من هذا القبيل

أو ربما يأتي الرمز الرئيسي من مكتبة C / C ++ ثم يستخدمون الإلكترون فقط من أجل واجهة المستخدم الرسومية ، لا أعرف ...

هل ترغب في معرفة كيفية حماية whatsapp و Slack لشفرة المصدر الخاصة بهما أيضًا

AFAIK هو ببساطة غير محمي. يمكنك استخراج app.asar الخاص بهم والوصول إلى شفرة المصدر. بالنسبة للأجزاء الحساسة من التطبيق ، عادةً ما تكتب وظائف إضافية مخصصة بلغة مجمعة مثل C / C ++ ، كما هو مقترح أعلاه.

كيف يمكننا تجميع كود c ++ فيه؟

راجع: https://nodejs.org/api/addons.html

تضمين التغريدة :)

مشترك

من الممكن أيضًا باستخدام node-ffi . يجب استخدام الإلكترون فقط لواجهة المستخدم.

قد يكون من المفيد استكشاف كتابة الكود في C / C ++ ثم استخدام أداة مثل emscripten لتحويله إلى تجميع ويب. يجب أن يعمل هذا بشكل رائع مع Chromium

يمكن تفكيك أي شيء / تفكيكه بجهد كافٍ. كتابة التعليمات البرمجية الخاصة بك في JavaScript وإدراجها في ASAR ستبعد غالبية الأشخاص. هل هناك سبب لحماية الكود لا يشمله حق المؤلف / الترخيص؟

2 سنتي هنا ، يبدو أن NW يحل مشكلة لقطات v8
https://nwjs.io/blog/js-src-protect-perf/

لقد صادفت هذه المقالة من nwjs ، "الكود الثنائي المترجم يعمل الآن بأسرع كود مصدر JS دون زيادة في الأداء" والذي كان 30٪ سابقًا ، وسيتم تشغيله افتراضيًا في الإصدار الأخير من NW.

مهتم حقًا بهذا ، أنا أيضًا أحمر المقالة التي أخبرتنا بهاcraftpip ويبدو أنها مثيرة للاهتمام إلى حد ما. إذا كان الإلكترون يتمتع بحماية الكود (حتى لو كان أبطأ عند نهاية المستخدم) ، فإن هذا سيجعل الكثير من المطورين يشعرون بالأمان والثقة أثناء كتابة تطبيقاتهم. امنحه فرصة فريق الإلكترون ؛)

إنه غير مريح للغاية للمطورين. استسلم وانتقل إلى NW ...

أرغب في مشاركة مشروع node.js الآخر الذي يستخدم حماية الكود بطريقة أنيقة للغاية: https://github.com/zeit/pkg

ربما هناك أمل في حماية المصدر في الإلكترون؟

بالإضافة إلى استخدام C ++ لبعض الأجزاء ، يمكنك أيضًا تصغير و _obfuscate_ مصدر JavaScript الخاص بك (على سبيل المثال باستخدام javascript-obfuscator ).

سيؤدي التصغير والتشويش معًا _ بشكل كبير_ إلى زيادة الجهد المطلوب (وبالتالي _ التكلفة_) "لسرقة" شفرتك ، وغالبًا ما يصل إلى النقطة التي تصبح فيها الهندسة العكسية للتطبيق بالكامل من نقطة الصفر أمرًا أكثر جدوى - ولا يوجد شيء تقنيًا يمكنك القيام به افعل بشأن الهندسة العكسية ، حتى لو أصبحت مواطنًا كاملاً (لا شيء سوى البحث عن القانون).

إذا لم تكن قلقًا بشأن إخفاء كود المصدر الخاص بك ولكنك تريد إخفاء أسرارك مثل:

• بيانات اعتماد OAuth
• عناوين URL التي لا يُقصد منها أن تكون معروفة للجمهور (أي نقاط نهاية الواجهة الخلفية الخاصة بواجهة برمجة التطبيقات)
• أوراق اعتماد REST API
• أي مفاتيح وأسرار
• كلمات السر

لقد قمت بإنشاء خدمة مجانية لمعالجة هذه المشكلة. اضطررت إلى القيام بذلك لأنني كنت أصنع تطبيقًا إلكترونيًا تجاريًا وكنت قلقًا بشأن سرقة بيانات الاعتماد الخاصة بي.

إنه يعمل عن طريق إنشاء تطبيق مساعد عبر الأنظمة الأساسية يقوم بتشغيل تطبيق الإلكترون الفعلي الخاص بك IFF لم يتم العبث بتطبيقك. بمجرد تشغيل التطبيق ، سيمرر بيانات الاعتماد الخاصة بك من خلال متغيرات البيئة.

معلومات اكثر:

مقدمة:
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.

كيف يعرف خادم الخادم البعيد حقًا أن العميل هو في الواقع تطبيق Electron الذي لم يتم تغييره؟
هذه هي المشكلة التي كنت أحاول حلها.

إذا كنت تستخدم أوث مع Client Credentials نوع المنحة، فبالتالي client_secret ما زال خبز في التطبيق الخاص بك ويمكن لأي شخص في نظرية قراءتها. مع وجود كود مصدر Electron مفتوحًا ومتاحًا بنسبة 100٪ ، من السهل البحث عن السلاسل التي تبدو "مثيرة للاهتمام".

لا توجد طريقة إثبات خادعة بنسبة 100٪ لحل المشكلة ولكني أعتقد أن الحل الذي أقدمه هو تحسين واضح.

أعتقد أن هذا ممكن من خلال بناء تطبيقات JS الخاصة بك باستخدام webpack أو إطار عمل SPA مثل angular2 / 4/6 أو vuejs2. يؤدي ذلك إلى تصغير الكود الخاص بك ومجهوداته حتى لو استخرج المرء ملف asar ، فقد يكون من الصعب عليهم قراءة الكود الخاص بك

أعتقد أن المشكلة لا ينبغي أن تركز فقط على التشفير الفعلي. ولكن في الحقيقة ، لم يتلاعب أي تطبيق / مستخدم آخر بكود المصدر الخاص بالعميل.

من خلال وجود ملف ثنائي مُوقَّع تم الحصول عليه من ASAR أو ثنائي مشابه يتم تحميل التعليمات البرمجية المصدر منه ، سيسمح للإلكترون بالتحقق من سلامة الملف. نظرًا لأنه يمكن دمج فحص السلامة في ثنائي الإلكترون نفسه ، فلن يكون هناك حمل زائد في كود جافا سكريبت. في الأساس ، يمكن أن يحصل الإلكترون على علم - بما في ذلك التحقق من السلامة ، وإلا فإن الطريقة العادية للقيام بذلك يتم تجميعها.

تضمين التغريدة

نظرًا لأنه يمكن دمج فحص السلامة في ثنائي الإلكترون نفسه ،

- إذن فالأمر يتعلق فقط باستخراج أي اختبار للتحقق من سلامة أو تشفير / فك تشفير Electron ، ولديك شفرة المصدر. أنا مقتنع بأن التشويش هو الطريقة الوحيدة التي يمكنك اتباعها هنا (سواء كان ذلك التصغير أو التصغير أو التعتيم أو تجميع الكود الأصلي).

هذا ، أو نقل جزء من رمز التطبيق الخاص بك إلى خدمة بعيدة (مع المصادقة إذا كنت بحاجة إلى الأمان).

يمكنك تشفير بياناتك وفك تشفيرها في وقت التشغيل وتحميلها مباشرة إلى متغيرات مثل الرموز أو أي نوع من البيانات الحساسة ، ولكن إذا كنت تتحدث عن تشفير ملفات جافا سكريبت بأكملها ، فسيؤثر ذلك على الأداء. يمكنك إعطاء لقطة لـ Node C ++ Addons

كما يقولها nodejs:

Node.js Addons عبارة عن كائنات مشتركة مرتبطة ديناميكيًا ، مكتوبة بلغة C ++ ، يمكن تحميلها في Node.js باستخدام الوظيفة تتطلب () ، واستخدامها تمامًا كما لو كانت وحدة Node.js عادية. يتم استخدامها بشكل أساسي لتوفير واجهة بين JavaScript يعمل في مكتبات Node.js و C / C ++.

في الأساس ، يقوم بتجميع الكود الخاص بك إلى ثنائي وبهذه الطريقة يمكنك تجريد الكود الخاص بك وسيكون الأداء أسرع كثيرًا ويمكنك إخفاء الكود الخاص بك إلى حد ما.

لا ، من السهل جدًا الحصول على شفرة المصدر الخاصة بك حتى عندما تقوم بتعبئتها في أرشيف asar ، لم يتم تصميم محرك V8 JavaScript مطلقًا لإخفاء شفرة المصدر. نجح NW.js في إخفاء ملف واحد من الكود المصدري تمامًا ، ولكن مع خفض سعر الأداء الملحوظ.

لذلك ، إذا كنت تريد حقًا حماية شفرة المصدر الخاصة بك ، فيجب عليك كتابتها بلغة C ++ وإنشاء وحدة Node module أصلية.

كيف يمكنني تعطيل devtools من إضافات c ++ وكيف يمكنني الوصول إلى جميع واجهة برمجة التطبيقات للإلكترون من الإضافات c ++ وهل هناك أي خطة لحزم تطبيق بدون أداة devtool ، قد يكون هذا مفيدًا لمنع الاختراقات وبأقل حجم للتطبيق ( @ زكبنز )

لقد سئمنا جميعًا من نشر رمز المصدر الخاص بنا. أنا أتحرك إلى nw

@ ahmtcn123 كيف يساعد تعليقك في حل هذه المشكلة؟

تريد إنشاء تطبيقات بتقنيات الويب التي تجعل شفرة المصدر عامة ، لذلك توقف عن هذا الموقف.

• يمكنك المساهمة في Electron لمعالجة هذه المشكلة
• اكتب وحدات C ++
• تصغير / تشويش / تشويش الكود الخاص بك (ولا تنسى تعطيل خرائط المصدر)
• يمكنك الانتقال إلى تقنية أخرى مماثلة (مثل nw.js) ، أو يمكنك أن تصبح محليًا
• تمت مشاركة بعض الحلول الأخرى هنا ، يمكنك مقايضة التشويش على الأداء (وهو ليس خيارًا واضحًا يجب اتخاذه عندما نعرف بالفعل أداء / استهلاك الموارد من Electron)

في صحتك!

_تعديل: حافظ على التصويت لأسفل يا رفاق 🍿

لماذا لا تدعم v8snapshot؟

أفهم أنه لا يمكننا حماية شفرة المصدر بالكامل. ولكن هناك طريقة أخرى تتمثل في إنشاء خدمة ويب باستخدام تقنية تجميع أصلية (مثل golang) لحماية التعليمات البرمجية المنطقية والاتصال من واجهة المستخدم الإلكترونية من خلال المضيف المحلي.

الكلمة الأخيرة

شمال غرب

لماذا تم إغلاق هذه القضية؟

لأن إخفاء كود المصدر كان دائمًا موضوعًا مثيرًا للجدل لأنه يعتبر الأمان من خلال الغموض طريقة سيئة للغاية لحماية التعليمات البرمجية الخاصة بك.

إذا كنت تريد بعض الحماية ، فاستخدم المزيد من الأساليب القياسية ، مثل المصادقة لتنفيذ الإجراءات الهامة والتشفير وما إلى ذلك.

مع خالص التقدير ، يمكنك كتابة تطبيقك على C وتوزيع الثنائيات ، وسوف نحصل على شفرة المصدر الخاصة بك على أي حال.

PD: يمكنك الوصول إلى الكود المصدري للأولاد الكبار (whatsapp web ، Slack ، team ، vscode) ولا أحد منهم يهتم به ، ربما كنت تفعل شيئًا خاطئًا.

"" "PD: يمكنك الوصول إلى الكود المصدري للأولاد الكبار (whatsapp web ، slack ، team ، vscode) ولا أحد منهم يهتم بهذا الأمر ، ربما كنت تفعل شيئًا خاطئًا." "

لا يمكن للمرء أن يقدم حجة غبية.

بيع البرامج دون الرغبة في تصميمها بطريقة عكسية واستخدامها بطرق لا يُفترض أن يكون أمرًا غير طبيعي ، في الواقع هناك قوانين محددة لذلك ، والتي لا تمنع المستخدمين من الاستمرار في القيام بذلك.

تضمين التغريدة

مع خالص التقدير ، يمكنك كتابة تطبيقك على C وتوزيع الثنائيات ، وسوف نحصل على شفرة المصدر الخاصة بك على أي حال.

استمر ، احصل على مصدر جميع التطبيقات الأكثر مبيعًا مثل Microsoft Word أو Photoshop أو حتى الألعاب الأكثر مبيعًا. هل انت ملياردير ولا علم لي ام ماذا؟

لا لول ، أنا لست مليارديرًا لأن امتلاك الكود المصدري لتلك البرامج لا جدوى منه ، فماذا ستفعل به؟

رجاء أيها الرجال ، هناك الكثير من الأشخاص في هذا الموضوع يتم إخطارهم بكل تعليق ، يرجى إبقائه بنّاءً.

ربما لتلخيص السبب ، في رأيي ، فإن الاضطرار إلى التعامل مع خصائص كود المصدر لجافا سكريبت لا يفسد الصفقات في كثير من الحالات:

• هناك الكثير من أمثلة التطبيقات / الخدمات المدرجة هنا مدفوعة إلى حد كبير بجرعتها ؛ خذ Twitter على سبيل المثال ، ليس لغزًا بالضبط كيف يعمل داخليًا ، ولكن حتى عن طريق نسخه بالكامل وإعادة إنتاجه بالكامل لن ينقلك إلى أي مكان بدون حركة المرور ، والإعلان ، والعلامة التجارية ، والبنية التحتية الداعمة ، إلخ.
• يجعل التعتيم المناسب من الصعب للغاية - بشكل وقائي - الوصول إلى الكود المصدري بأي طريقة ذات مغزى ، لدرجة أنه يصبح أكثر جدوى بكثير من مراقبة سلوك التطبيق نفسه وعكس هندسته بناءً على ذلك ، دون الاعتماد على الأصل كود المصدر - يشبه إلى حد كبير في حالة C ++
• إن سرقة الأفكار و / أو الحلول من تطبيق محمي بموجب قانون حقوق النشر هو سؤال قانوني وليس تقنيًا ، وعلى هذا النحو ، فإن حماية التنفيذ هي شأن قانوني ، بغض النظر عن مستوى الحماية المطبقة ؛ ستسرق شركة صينية مريبة شعارك وتطبيقك دون مشاكل ، بغض النظر عما إذا كان مكتوبًا بلغة JavaScript أو Assembly
• بالإضافة إلى ذلك ، يمكنك تضمين كود C ++ في التطبيق الخاص بك إذا لم تكن مقتنعًا بالتعتيم ، أو يمكنك نقل الكود إلى خدمة بعيدة والتي ، على عكس كل شيء آخر (بما في ذلك C ++) ، محمية تمامًا من الفحص المباشر (وليس من الهندسة العكسية) على أية حال)

JohnWeisz قال الكثير من الأشياء المعقولة حقًا. سأضيف أيضًا أنه إذا لم يكن ذلك كافيًا بالنسبة لك ، فيمكنك استخدام WebAssembly اليوم. فيما يتعلق بحماية الكود المصدري ، يجب أن يكون ذلك جيدًا جدًا.

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

kidandcat هل هذا صحيح؟ "مع خالص التقدير ، يمكنك كتابة تطبيقك على C وتوزيع الثنائيات ، وسوف نحصل على شفرة المصدر الخاصة بك على أي حال."

لقد بحثت على google ، ويبدو أنه من المستحيل الحصول على شفرة المصدر من الثنائيات التي تم تجميعها من C / C ++. على الأكثر ، يمكننا الحصول على بيانات التجميع.

أنا أقوم بتطوير برنامج سطح مكتب تجاري لنظام التشغيل Windows. منطق الكود هو اختصاص رئيسي. يجب أن يعمل هذا المنطق من جانب العميل ولكني لا أريد أن يحصل عليه المنافسون. لذا فإن حماية الكود هي بمثابة كسر للصفقة في حالتي.

@ z1988hf

يبدو أنه من المستحيل الحصول على الكود المصدري من الثنائيات المترجمة من C / C ++. على الأكثر ، يمكننا الحصول على بيانات التجميع

ما يعنيه هذا حقًا هو أنه يمكنك إلى حد كبير إجراء هندسة عكسية لشفرة المصدر الأصلية ، أو ما يعادلها ، إلا أنها عادة ما تكون صعبة للغاية وبالتالي باهظة الثمن. يمكن قول الشيء نفسه عن الكود المبهم.

kidandcat هل هذا صحيح؟ "مع خالص التقدير ، يمكنك كتابة تطبيقك على C وتوزيع الثنائيات ، وسوف نحصل على شفرة المصدر الخاصة بك على أي حال."

لقد بحثت على google ، ويبدو أنه من المستحيل الحصول على شفرة المصدر من الثنائيات التي تم تجميعها من C / C ++. على الأكثر ، يمكننا الحصول على بيانات التجميع.

أنا أقوم بتطوير برنامج سطح مكتب تجاري لنظام التشغيل Windows. منطق الكود هو اختصاص رئيسي. يجب أن يعمل هذا المنطق من جانب العميل ولكني لا أريد أن يحصل عليه المنافسون. لذا فإن حماية الكود هي بمثابة كسر للصفقة في حالتي.

كما أن التجميع هو رفيق الكود ، سيكون منطقك هناك. ستحتاج إلى القيام بأشياء أكثر لحماية التعليمات البرمجية الخاصة بك أكثر من مجرد تجميعها. (ولكن كما قال JohnWeisz ، فإن برامج الهندسة العكسية باهظة الثمن ، لذلك لن تقلق إذا لم يكن منافسوك مهتمين برمي بعض الآلاف من الدولارات لمجرد تجربتها)

بالنسبة لأولئك الذين يشيرون إلى تطبيقات مثل Slack على أنها لا تهتم بحماية شفرة المصدر ، فهذه ليست أفضل مقارنة لجميع التطبيقات. Slack هي خدمة تعيش عبر الإنترنت وتطبيق الإلكترون الخاص بهم هو مجرد غلاف لعرض تطبيق الويب الخاص بهم. غالبية الصلصة السرية للتطبيقات مثل Slack تعيش على خوادم الويب.

بالنسبة لأولئك الذين يشيرون إلى تطبيقات مثل Slack على أنها لا تهتم بحماية شفرة المصدر ، فهذه ليست أفضل مقارنة لجميع التطبيقات. Slack هي خدمة تعيش عبر الإنترنت وتطبيق الإلكترون الخاص بهم هو مجرد غلاف لعرض تطبيق الويب الخاص بهم. غالبية الصلصة السرية للتطبيقات مثل Slack تعيش على خوادم الويب.

@المفضلة لديك
ماذا عن Spotify !!! ، نحن نعرف ماذا تقصد ولكن ماذا عن التطبيقات غير المتصلة بالإنترنت ؟؟

صلصةannymosse Spotify

yourfavorite فقط ألقِ نظرة على مصدرها ، ضع في اعتبارك أحيانًا أننا لا نخفي مصدرنا للتطبيقات التجارية ، نحن نفعل ذلك لمنع خدماتنا بعيدًا عن المتسللين الذين يحصلون على بعض الخطوط الضعيفة ، على أي حال ، نحتاج فقط إلى هذه الميزة إذا هناك إمكانية للقيام بذلك ، على الأقل بعض الطرق لتمرير asar files و package.json و *.js

أنا لا أجادل ضد حماية التعليمات البرمجية المصدر ، ولكن بدلاً من ذلك ، من المحتمل ألا تكون Slack و Spotify أفضل مقارنات لما يفعله معظم الأشخاص مع الإلكترون. بالإضافة إلى ذلك ، إذا كانت حماية رمز المصدر أمرًا بالغ الأهمية لمنتجك ، فربما لا يكون الإلكترون هو الأفضل في هذا الوقت.

ولكي أكون واضحًا ، أنا أؤيد حماية شفرة المصدر من نوع ما على الإلكترون.

أحتاج حماية شفرة المصدر. اسمحوا لي أن أقدم حالة استخدام هنا:

أحاول إنشاء قاعدة برامج ترجمة على Google Translate API

يسحب المستخدم ملف ترجمة. srt / .ass إلى البرنامج ، وسيستخدم البرنامج Google Translate API لترجمة كل سطر على حدة.

مثال

قام المستخدم بتنزيل مقطع فيديو واحد وعنوان فرعي واحد باللغة الإنجليزية.
الآن يمكنهم استخدام هذا البرنامج لترجمة الترجمة الإنجليزية
إلى اللغة الصينية أو أي لغات أخرى.
حتى يتمكنوا من فهم المحتوى.

مشكلة

إذا كان من السهل الحصول على شفرة المصدر.
يبدو أن المهاجم قد يحصل على مفتاح API الخاص بي وسري. وإساءة استخدامها.
وسأتلقى فاتورة ضخمة من Google (500 دولار؟ 1000 دولار؟ أكثر؟)

تحديث سريع (2020 - مارس - 29)

أنا أستخدم Vue.js + Webpack مع Electron.js
لذلك سيتم تصغير كل الشفرة ، لذا لم تعد هناك مشكلة

@ 1c7

حسنًا ، ربما يجب أن تستخدم بعض الحماية الخارجية لتحقيق ذلك. يمكنني بسهولة الحصول على مفتاح API الخاص بك من برنامج C ++ أيضًا ، لا مشكلة. لذا فهذه ليست قضية خاصة بالإلكترون.

lvkins أوه أرى. لم أكن أعرف أن برنامج C ++ به هذه المشكلة أيضًا. أنا لست على دراية بهذه اللغة.
شكرا على النصائح!

يمكن إجراء هندسة عكسية لكل لغة برمجة. كان دائما مصدر قلق كبير. صحيح أن أي حماية أفضل من عدم وجود حماية ، لكنها لا تزال ؛ نحتاج إلى بذل بعض الجهد الإضافي لحماية البيانات الحساسة ، بغض النظر عن لغة البرمجة. في حالتك ، ربما يجب عليك الذهاب إلى مكتبة C ++ ، ووضع بعض الملح الإضافي عليها وربطها بـ node.js الخاص بك ، وهذا يجب أن يفعل ذلك.

lvkins أنت ترد علي ، أليس كذلك؟
شكرا على اقتراحك. سأحقق في هذا.

أريد استخدام Electron.js لأنني أريد أن يكون برنامج الترجمة هذا قادرًا على العمل على كل من نظامي التشغيل Mac و Windows.

يبدو أن Electron.js + بعض C ++ يمكن أن تحمي مفتاح وسر API الخاص بي

شكرا lvkins

@ 1c7 في الواقع 😃

ابدأ من هنا: https://nodejs.org/api/addons.html

إذا كان الافتقار التام للإلكترون للأمان يثير قلقك ، فيمكنك أيضًا تجربة NW.js.

حظا طيبا وفقك الله!

@ 1c7 ولماذا لا لينكس؟ !! أعتقد أنه نفس الكود الأساسي لجميع المنصات ، أليس كذلك؟!

annymosse لقد نسيت أن أذكر Linux ، لا شيء ضد Linux.

لمعلوماتك:

• أنا أستخدم Macbook Pro 2017 مقاس 15 بوصة (Mac)
• يستخدم معظم المستخدمين الخاص بي Windows (Windows)
• لم أشاهد أيًا من مستخدمي البرنامج الخاص بي يستخدمه على Linux (Linux)

كنت أفكر في تحويل https://github.com/1c7/Translate-Subtitle-File
هذا المشروع في مشروع جاد (اشحن المال وجودة أعلى (اقض المزيد من الوقت عليه))
لذلك أقوم ببحثي الآن

ستستهدف هذه الأداة في الغالب سوق الصين في الوقت الحالي. (سيكون كل الزر والنص بالصينية)
i18n على الخريطة ولكن لن يكون قريبًا

كان لدي خطة لإنشاء i18n & Yandex translator API ولكن بسبب نفس المشكلة ألغيت المشروع ، ثم في Linux ، لم يكن لدى معظم المستخدمين الجدد ثقة في البرامج التي يعتقدون أنها غير موجودة في Linux أو لا يوجد بديل لذلك إذا قمت بإنشاء هذا المشروع وكان المستخدمون المستهدفون لديك يقومون فقط بترجمة الوسائط ، فيمكنهم استخدام أي توزيعة Linux أو التوزيع المفضل لدي في العمق (توزيعة Linux الصينية) ، آمل أن يكون الأفضل لك ولجميع مستخدمي Linux.

يجب ألا تكون مفاتيح وسر واجهة برمجة التطبيقات في أي تطبيق منشور. بدلا من ذلك
عليها على واجهات برمجة التطبيقات / الواجهة الخلفية ، قم بحمايتها بنوع من ملفات
المصادقة / الاختناق. ثم اجعل تطبيقك يستهلك واجهات برمجة التطبيقات الخاصة بك.

Em dom، 20 de out de 2019 10:22، Cheng Zheng [email protected]
escreveu:

annymosse https://github.com/annymosse لقد نسيت للتو ذكر Linux ،
لا شيء ضد لينكس

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/electron/electron/issues/2570؟
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ADCOXMCKPUOMQPM3JKZP5J3QPRLQRANCNFSM4BODX2FQ
.

توجد مكتبة تسمى bytenode تتيح لك تحويل ملفات Javascript إلى ملفات ثنائية حتى لا يتمكن أي شخص من قراءتها.

قم أولاً بتثبيت bytenode على الخادم والمجلد الخاص بك:

>npm i -g bytenode
>npm i bytenode

قم بإنشاء ملف nodeJS عادي مع الكود التالي فيه. لنتخيل أننا نسمي الكود التالي: 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" لترى أنه ثنائي بالفعل وأن لا أحد لا يمكنه رؤية الكود الخاص بك. يمكنك نقل ملف js التجريبي العادي الأصلي إلى موقع آخر.
لم أختبرها من الإلكترون ولكن أعتقد أنها ستنجح ، أليس كذلك؟