Electron: Ist die Quelle beim Erstellen von Apps mit Electron wirklich geschützt?

Nein, es ist sehr einfach, Ihren Quellcode zu erhalten, selbst wenn Sie ihn in ein asar Archiv gepackt haben. Die V8-JavaScript-Engine ist nie darauf ausgelegt, Quellcode zu verbergen. NW.js schafft es, eine Datei des Quellcodes vollständig zu verbergen, jedoch mit dem Preis eines erheblichen Leistungsabfalls.

Wenn Sie also Ihren Quellcode wirklich schützen möchten, müssen Sie ihn in C++ schreiben und ein natives Node-Modul erstellen.

Es gibt einige Optionen, aber das Schutzniveau, das sie bieten, wird durch die von @zcbenz genannten Gründe

• Sie könnten selbst eine Entschlüsselungslogik in einem C++-Knoten-Addon implementieren, aber sie wird wahrscheinlich immer noch zerbrechlich sein (zB das Programm debuggen und die Quelle nach der Entschlüsselung, aber vor der Prüfung kopieren).
• Es gibt auch EncloseJS , das behauptet, Ihren Code für node.js/io.js zu kompilieren, sodass es möglicherweise mit Electron funktioniert.
• nw.js , ein ähnliches Projekt, unterstützt v8-Snapshots, die eine Art Schutz bieten (siehe Details hier ).

Beachten Sie, dass alle diese Methoden zu Leistungseinbußen führen.

@etiktin Ich
Ist es möglich, den node.js-Code einfach direkt im C++-Add-On anzuwenden?

@fritx , Node hat ein Modul namens vm, das Code auswerten kann. Ich denke, Sie könnten einen Weg finden, es aufzurufen, oder es unterstreicht die C++-API von Ihrem Addon und verwendet es, um Ihren Code zu laden.
Denken Sie daran, dass der Benutzer es immer noch schaffen könnte, die Entwicklertools zu öffnen und das geladene Skript anzuzeigen. Selbst wenn Sie es schaffen, dies mit einem benutzerdefinierten Electron-Build zu blockieren und das Add-On zu überprüfen, um zu sehen, dass Ihr Electron-Build nicht manipuliert wurde, könnte der Benutzer Ihren Code immer noch als Zeichenfolge im Speicher sehen.

Klingt gut, schützen Sie die Quelle! :Schlüssel:

Dann habe ich eine Frage, wie Closed-Code-Elektron-Apps wie GitKraken, Whatsapp oder Slack den Code verbergen können ?

@alexis57 Ich habe die gleiche Frage; Vielleicht ist es nur das Inspect-Element deaktiviert oder so

Oder vielleicht kommt der Hauptcode aus einer C/C++-Bibliothek und dann verwenden sie Electron nur für die GUI, weiß nicht...

Würde gerne wissen, wie WhatsApp und Slack auch ihren Quellcode schützen

AFAIK ist es einfach ungeschützt. Sie können ihre app.asar extrahieren und auf den Quellcode zugreifen. Für sensible Teile der Anwendung schreiben Sie normalerweise benutzerdefinierte Add-Ons in einer kompilierten Sprache wie C/C++, wie oben vorgeschlagen.

Wie können wir darin C++-Code kompilieren?

Siehe: https://nodejs.org/api/addons.html

@boeserwolf danke! :)

Gezeichnet

Es ist auch mit node-ffi . Electron sollte nur für die Benutzeroberfläche verwendet werden.

Es könnte sich lohnen, den Code in C/C++ zu schreiben und ihn dann mit einem Tool wie emscripten in eine

Alles kann mit genügend Aufwand demontiert / enttarnt werden. Wenn Sie Ihren Code in JavaScript schreiben und ihn in die ASAR einbinden, würde die Mehrheit der Leute draußen bleiben. Gibt es einen Grund für den Schutz des Codes, den das Urheberrecht/die Lizenzierung nicht abdeckt?

Meine 2 Cent hier, NW scheinen das Problem der v8-Schnappschüsse zu lösen
https://nwjs.io/blog/js-src-protect-perf/

Ich bin auf diesen Artikel von nwjs gestoßen, "kompilierter Binärcode läuft jetzt so schnell wie JS-Quellcode ohne Performance-Overhead", der zuvor 30% betrug und in der späteren Version von NW standardmäßig aktiviert wird.

Wirklich interessiert daran, habe ich auch den Artikel, den @craftpip uns erzählt hat,

Für Entwickler ist es zu unbequem. Aufgeben und zu NW wechseln...

Ich möchte andere node.js-Projekte teilen, die auf sehr elegante Weise Codeschutz verwenden: https://github.com/zeit/pkg

Vielleicht gibt es Hoffnung auf Quellenschutz in Electron?

Zusätzlich zur Verwendung von C++ für einige Teile können Sie Ihre JavaScript-Quelle auch verkleinern und _verdecken_ (zB mit Javascript-Obfuscator ).

Minimierung und Verschleierung zusammen werden den erforderlichen Aufwand (und damit die _Kosten_) _dramatisch_ erhöhen, um Ihren Code zu "stehlen", oft bis zu dem Punkt, dass ein Reverse-Engineering Ihrer gesamten Anwendung von Grund auf leicht machbar wird - und technisch gesehen gibt es nichts, was Sie können Reverse-Engineering tun, auch wenn Sie vollständig nativ sind (nichts, außer nach dem Gesetz zu suchen).

Wenn Sie sich keine Sorgen machen, Ihren Quellcode zu verstecken, ABER Sie Ihre Geheimnisse verbergen möchten, wie zum Beispiel:

• OAuth-Anmeldedaten
• URLs, die nicht öffentlich bekannt sein sollen (z. B. private Back-End-API-Endpunkte)
• REST API-Anmeldeinformationen
• Alle Schlüssel und Geheimnisse
• Passwörter

Ich habe einen KOSTENLOSEN Service erstellt, um dieses Problem zu beheben. Ich musste es schaffen, weil ich eine kommerzielle Elektron-App erstellte und mir Sorgen machte, dass meine Zugangsdaten gestohlen werden könnten.

Es funktioniert, indem es eine plattformübergreifende Hilfsanwendung erstellt, die Ihre eigentliche Elektronenanwendung startet. IFF, an der Ihre Anwendung nicht manipuliert wurde. Sobald die Anwendung gestartet wird, leitet sie Ihre Anmeldeinformationen durch die Umgebungsvariablen weiter.

Mehr Informationen:

Einführung:
https://medium.com/@rocketlaunchr.cloud/introducing -electron-vault-d09ade2c2020

Dokumentation:
https://rocketlaunchr.github.io/electron-vault-docs/

@JohnWeisz

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

Woher weiß der Remote-Server wirklich, dass der Client tatsächlich Ihre unveränderte Electron-App ist?
Das ist das Problem, das ich zu lösen versuchte.

Wenn Sie OAuth mit dem Grant-Typ Client Credentials verwenden, ist Ihr client_secret immer noch in Ihre Anwendung eingebunden und kann theoretisch jeder lesen. Mit dem zu 100 % offenen und verfügbaren Electron-Quellcode ist es einfach, nach Strings zu suchen, die "interessant" erscheinen.

Es gibt keinen 100% narrensicheren Weg, das Problem zu lösen, aber ich glaube, meine Lösung ist eine definitive Verbesserung.

Ich glaube, dies ist möglich, indem Sie Ihre JS-Apps mit Webpack- oder SPA-Frameworks wie angle2/4/6 oder vuejs2 erstellen. Dies minimiert Ihren Code und ist mühsam, obwohl man die ASAR-Datei extrahiert, kann es für sie schwierig sein, Ihren Code zu lesen

Ich denke, das Thema sollte sich nicht nur auf die eigentliche Verschlüsselung konzentrieren. Aber darauf, dass keine andere Anwendung/Benutzer den Quellcode des Clients manipuliert hat.

Durch eine signierte ASAR-Archivierung oder eine ähnliche Binärdatei, aus der der Quellcode geladen wird, kann Electron die Integrität der Datei überprüfen. Da die Integritätsprüfung in die Elektronen-Binärdatei selbst integriert werden könnte, würde es keine Überlastung des Javascript-Codes geben. Grundsätzlich könnte das Elektron beim Build ein Flag erhalten --include-integrity-check, ansonsten wird die normale Vorgehensweise kompiliert.

@tulpn

Da die Integritätsprüfung in die Elektronenbinärdatei selbst integriert werden könnte, gäbe es keine ...

-- dann ist es nur noch eine Frage des Extrahierens der Integritätsprüfung oder Verschlüsselung/Entschlüsselung von Electron, und Sie haben den Quellcode. Ich bin überzeugt, dass Verschleierung der einzige Ansatz ist, den Sie hier wählen können (sei es Verkleinerung, Verkleinerung + Verschleierung oder native Codekompilierung).

Das oder das Verschieben eines Teils Ihres App-Codes in einen Remotedienst (mit Authentifizierung, wenn Sie Sicherheit benötigen).

Sie können Ihre Daten verschlüsseln und zur Laufzeit entschlüsseln und direkt in Variablen wie Token oder jede Art von sensiblen Daten laden, aber wenn Sie über die Verschlüsselung ganzer Javascript-Dateien sprechen, wird dies die Leistung beeinträchtigen. Sie können Node C++ Addons ausprobieren

Wie es nodejs sagt:

Node.js-Addons sind dynamisch verknüpfte Shared Objects, geschrieben in C++, die mit der Funktion require() in Node.js geladen und wie ein gewöhnliches Node.js-Modul verwendet werden können. Sie werden hauptsächlich verwendet, um eine Schnittstelle zwischen JavaScript, das in Node.js ausgeführt wird, und C/C++-Bibliotheken bereitzustellen.

Im Grunde kompiliert es Ihren Code in Binärdatei und auf diese Weise können Sie Ihren Code abstrahieren und die Leistung wird viel schneller sein und Sie können Ihren Code bis zu einem gewissen Grad verbergen.

Nein, es ist sehr einfach, Ihren Quellcode zu erhalten, selbst wenn Sie ihn in ein asar Archiv gepackt haben. Die V8-JavaScript-Engine ist nie darauf ausgelegt, Quellcode zu verbergen. NW.js schafft es, eine Datei des Quellcodes vollständig zu verbergen, jedoch mit dem Preis eines erheblichen Leistungsabfalls.

Wenn Sie also Ihren Quellcode wirklich schützen möchten, müssen Sie ihn in C++ schreiben und ein natives Node-Modul erstellen.

Wie kann ich deaktivieren devtools von c ++ Addons und , wie ich all die API von Elektron von c ++ Addons zugreifen können und ist dort jeder Plan eine App ohne DevTool zu verpacken diese hilfsbereit kann die Hacks und mit weniger Größe der Anwendung zu verhindern (@ zcbenz )

Wir alle haben es satt, dass unser Quellcode veröffentlicht wird. ich ziehe nach neu

@ahmtcn123 Wie hilft Ihr Kommentar bei der Lösung dieses Problems?

Sie möchten Apps mit Webtechs erstellen, deren Quellcode im Wesentlichen öffentlich ist, also hören Sie mit dieser Einstellung auf.

• Sie können zu Electron beitragen, um dieses Problem anzugehen
• C++-Module schreiben
• Verkleinern / verschleiern / verstümmeln Sie Ihren Code (und vergessen Sie nicht, Quellzuordnungen zu deaktivieren)
• Sie können zu einer anderen ähnlichen Technologie (wie nw.js) wechseln oder nativ gehen
• Einige andere Lösungen wurden hier geteilt, Sie können Verschleierung gegen Leistung eintauschen (was eine nicht so offensichtliche Wahl ist, wenn wir die Leistung / den Ressourcenverbrauch von Electron bereits kennen).

Danke schön!

_edit: Stimmen Sie weiter ab, Jungs_ 🍿

Warum nicht v8snapshot unterstützen?

Ich verstehe, dass wir den Quellcode nicht vollständig schützen können. aber eine andere Möglichkeit kann das Erstellen von Webdiensten mit nativer kompilierter Technologie (wie Golang) zum Schutz von Logikcode und Aufrufen von der elektronischen Benutzeroberfläche über localhost sein.

das letzte Wort

NW

warum wurde dieses Thema geschlossen?

Da Code hidding Quelle ist schon immer ein umstrittenes Thema , weil es gilt als Sicherheit durch Unklarheit eine sehr schlechte Methode , um Ihren Code zu schützen.

Wenn Sie einen gewissen Schutz wünschen, verwenden Sie Standardmethoden wie Authentifizierung, um kritische Aktionen auszuführen, Verschlüsselung usw.

Mit freundlichen Grüßen, Sie können Ihre App auf C schreiben und Binärdateien verteilen, wir bekommen Ihren Quellcode trotzdem.

PD: Sie können auf den Quellcode der großen Jungs zugreifen (Whatsapp Web, Slack, Teams, vscode) und keiner kümmert sich darum, vielleicht machen Sie etwas falsch.

"""PD: Sie können auf den Quellcode der großen Jungs zugreifen (Whatsapp-Web, Slack, Teams, vscode) und keiner kümmert sich darum, vielleicht machen Sie etwas falsch."""

Dümmer kann man kaum argumentieren.

Software zu verkaufen, ohne zu wollen, dass sie zurückentwickelt und auf eine Weise verwendet wird, die es nicht sollte, ist nicht ungewöhnlich. Tatsächlich gibt es genau dafür Gesetze, die Benutzer nicht davon abhalten, es trotzdem zu tun.

@kidandcat

Mit freundlichen Grüßen, Sie können Ihre App auf C schreiben und Binärdateien verteilen, wir bekommen Ihren Quellcode trotzdem.

Fahren Sie fort, holen Sie sich die Quelle aller meistverkauften Apps wie Microsoft Word, Photoshop oder sogar die meistverkauften Spiele. Sind Sie ein Milliardär und ich weiß es nicht oder was?

Nein, lol, ich bin kein Milliardär, weil es nutzlos ist, den Quellcode dieser Programme zu haben, was willst du damit machen?

Leute, bitte, es gibt viele Leute in diesem Thread, die für jeden Kommentar benachrichtigt werden, bitte bleibt konstruktiv.

Um vielleicht zusammenzufassen, warum der Umgang mit den Quellcode-Besonderheiten von JavaScript meiner Meinung nach in vielen Fällen kein Deal-Breaker ist:

• Viele der hier aufgeführten Beispiel-Apps/-Dienste werden hauptsächlich von ihrer _Traktion_ angetrieben; Nehmen Sie zum Beispiel Twitter, es ist nicht gerade ein Rätsel, wie es intern funktioniert, aber selbst wenn Sie es vollständig kopieren und vollständig reproduzieren, werden Sie ohne den Verkehr, die Werbung, die Marke, die unterstützende Infrastruktur nicht weiterkommen, usw.
• Eine ordnungsgemäße Verschleierung macht es extrem _unerlaubt_ schwierig, auf sinnvolle Weise auf den Quellcode zuzugreifen, bis zu dem Punkt, an dem es viel einfacher wird, das Verhalten der Anwendung selbst zu beobachten und sie basierend darauf zurückzuentwickeln, ohne sich auf das Original zu verlassen Quellcode -- ähnlich wie im Fall von zB C++
• Ideen und/oder Lösungen aus einer urheberrechtlich geschützten Anwendung zu stehlen ist eine Rechtsfrage, keine technische, und der Schutz der Implementierung ist als solche eine Rechtsangelegenheit, unabhängig vom implementierten Schutzniveau; eine faule chinesische Firma wird Ihr Logo und Ihre App ohne Probleme stehlen, egal ob sie in JavaScript oder Assembly geschrieben wurden
• Darüber hinaus können Sie C++-Code in Ihre Anwendung einbinden, wenn Sie nicht von Verschleierung überzeugt sind, oder Sie können Code in einen Remote-Dienst verschieben, der im Gegensatz zu allem anderen (einschließlich C++) perfekt vor direkter Inspektion (nicht vor Reverse-Engineering) geschützt ist obwohl)

@JohnWeisz hat viele wirklich vernünftige Dinge gesagt. Ich werde auch hinzufügen, dass Sie WebAssembly noch heute verwenden können, wenn es Ihnen nicht ausreicht. In Bezug auf den Schutz des Quellcodes sollte das ziemlich gut sein.

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

@kidandcat Stimmt das?" Mit freundlichen Grüßen, Sie können Ihre App auf C schreiben und Binärdateien verteilen, wir erhalten Ihren Quellcode trotzdem."

Ich habe bei Google gesucht, es scheint unmöglich zu sein, Quellcode aus Binärdateien zu erhalten, die aus C/C++ kompiliert wurden. Wir können höchstens Assembly-Anweisungen erhalten.

Ich entwickle eine kommerzielle Windows-Desktop-Software. Codelogik ist Schlüsselkompetenz. Diese Logik muss auf der Client-Seite ausgeführt werden, aber ich möchte nicht, dass meine Konkurrenten sie bekommen. Code-Schutz ist also in meinem Fall ein Dealbreaker.

@z1988hf

scheint es unmöglich zu sein, Quellcode aus Binärdateien herauszuholen, die aus C/C++ kompiliert wurden. Wir können höchstens Assembly-Anweisungen erhalten

Das bedeutet wirklich, dass Sie den ursprünglichen Quellcode oder etwas Äquivalentes so ziemlich zurückentwickeln können, nur dass es normalerweise unerschwinglich und daher teuer ist. Das gleiche gilt für verschleierten Code.

@kidandcat Stimmt das?" Mit freundlichen Grüßen, Sie können Ihre App auf C schreiben und Binärdateien verteilen, wir erhalten Ihren Quellcode trotzdem."

Ich habe bei Google gesucht, es scheint unmöglich zu sein, Quellcode aus Binärdateien zu erhalten, die aus C/C++ kompiliert wurden. Wir können höchstens Assembly-Anweisungen erhalten.

Ich entwickle eine kommerzielle Windows-Desktop-Software. Codelogik ist Schlüsselkompetenz. Diese Logik muss auf der Client-Seite ausgeführt werden, aber ich möchte nicht, dass meine Konkurrenten sie bekommen. Code-Schutz ist also in meinem Fall ein Dealbreaker.

Auch Assembly ist Code-Mate, Ihre Logik wird da sein. Sie müssen mehr tun, um Ihren Code zu schützen, als ihn nur zu kompilieren. (Aber wie @JohnWeisz sagte, Reverse-Engineering-Software ist sehr teuer, so dass Sie sich keine Sorgen machen müssen, wenn Ihre Konkurrenten nicht daran interessiert sind, einige Tausend Dollar zu werfen, nur um es auszuprobieren)

Für diejenigen, die auf Apps wie Slack verweisen, die sich nicht um den Schutz des Quellcodes kümmern, ist dies nicht der beste Vergleich für alle Apps. Slack ist ein Dienst, der online lebt, und ihre Elektron-App ist nur eine Shell zum Anzeigen ihrer Web-App. Der Großteil der geheimen Soße von Apps wie Slack lebt auf Webservern.

Für diejenigen, die auf Apps wie Slack verweisen, die sich nicht um den Schutz des Quellcodes kümmern, ist dies nicht der beste Vergleich für alle Apps. Slack ist ein Dienst, der online lebt, und ihre Elektron-App ist nur eine Shell zum Anzeigen ihrer Web-App. Der Großteil der geheimen Soße von Apps wie Slack lebt auf Webservern.

@dein Favorit
Wie wäre es mit Spotify !!!, wir wissen was du meinst, aber wie ist es mit den Offline-Apps?

@annymosse Spotifys geheime Soße ist nicht ihre App. Wenn jemand die Quelle der Spotify-App stehlen würde, wäre das nicht wirklich wichtig. Die App ist gut genug. Der wahre Grund, warum die Leute Spotify nutzen und dafür bezahlen, ist das Inhaltsangebot und die Bequemlichkeit des Musik-Streamings. Es gibt einige UX-Details, die wahrscheinlich von vielen Spotify-Kunden Alternativen vorgezogen werden, aber Konkurrenten brauchen den Quellcode nicht wirklich, um das zu kopieren. Außerdem habe ich nicht versucht, mir den Quellcode von Spotify anzusehen, aber ich könnte mir vorstellen, dass irgendwo eine Art Schutz in die App integriert ist. Wahrscheinlich eine solide Verschleierung sowie native C-Addons. Ich denke, dies wäre aufgrund von DRM eine Voraussetzung für sie.

@yourfavorite werfen Sie einfach einen Blick auf die Quelle, denken Sie daran, manchmal verstecken wir unsere Quelle nicht für kommerzielle Apps, wir tun dies, um unsere Dienste weitaus zu verhindern als Hacker, die einige Schwachstellen bekommen, sowieso brauchen wir diese Funktion nur, wenn es gibt eine Möglichkeit, dies zu tun, zumindest eine Methode, um die asar files und die package.json und *.js

Ich argumentiere nicht gegen den Schutz des Quellcodes, sondern eher, dass Slack und Spotify wahrscheinlich nicht die besten Vergleiche für das sind, was die meisten Leute mit Elektron machen. Wenn außerdem der Schutz des Quellcodes für Ihr Produkt von entscheidender Bedeutung ist, ist Elektron derzeit möglicherweise nicht die beste Lösung.

Und um es klar zu sagen, ich bin dafür, dass der Quellcodeschutz in irgendeiner Form zu Electron kommt.

Ich brauche Quellcodeschutz. Lassen Sie mich hier einen Anwendungsfall vorstellen:

Ich versuche, eine Übersetzungssoftwarebasis auf der Google Translate API aufzubauen

Der Benutzer zieht eine .srt/.ass-Untertiteldatei in die Software, und die Software würde die Google Translate API verwenden, um jede einzelne Zeile zu übersetzen.

Beispiel

Der Benutzer hat 1 Video und den 1 englischen Untertitel heruntergeladen.
Jetzt können sie diese Software verwenden, um diesen englischen Untertitel zu übersetzen
ins Chinesische oder andere Sprachen.
So können sie den Inhalt verstehen.

Problem

Wenn Quellcode leicht zu bekommen ist.
anscheinend konnte Angreifer meinen API-Schlüssel&Geheimnis bekommen. und missbrauche es.
und ich würde eine massive Rechnung von Google erhalten (500 $? 1000 $? mehr?)

Schnelles Update (2020-März-29)

Ich verwende Vue.js + Webpack mit Electron.js
damit der gesamte Code minimiert würde, ist es also kein Problem mehr

@1c7

Nun, vielleicht sollten Sie einen externen Schutz verwenden, um dies zu erreichen. Ich könnte Ihren API-Schlüssel auch problemlos aus einer C++-Software abrufen, kein Problem. Dies ist also nicht wirklich ein elektronenspezifisches Problem.

@lvkins oh ich
Danke für die Tipps!

Grundsätzlich kann jede Programmiersprache zurückentwickelt werden. Es war immer ein großes Anliegen. Es stimmt, dass jeder Schutz besser ist als kein Schutz, aber trotzdem; Wir müssen zusätzliche Anstrengungen unternehmen, um die sensiblen Daten zu schützen, egal in welcher Programmiersprache. In Ihrem Fall sollten Sie sich wahrscheinlich für eine C++-Bibliothek entscheiden, etwas zusätzliches Salt hinzufügen und mit Ihrer node.js verknüpfen. Das sollte es tun.

@lvkins Du antwortest mir richtig?
Danke für den Vorschlag. Ich würde das untersuchen.

Ich möchte Electron.js verwenden, weil ich möchte, dass diese Übersetzungssoftware sowohl auf Mac als auch auf Windows ausgeführt werden kann.

Scheint so, als ob Electron.js + etwas C++ meinen API-Schlüssel&Geheimnis schützen könnte

Danke @lvkins

@1c7 In der Tat

Beginnen Sie hier: https://nodejs.org/api/addons.html

Wenn Sie die völlige Sicherheitslücke von Electron beunruhigen, können Sie auch NW.js ausprobieren.

Viel Glück!

@1c7 und warum nicht Linux?!! Ich denke, es ist die gleiche Codebasis für alle Plattformen, richtig??!

@annymosse Ich habe gerade vergessen, Linux zu erwähnen, nichts gegen Linux.

Zu Ihrer Information:

• Ich verwende ein Macbook Pro 2017 15 Zoll (Mac)
• Die meisten meiner Benutzer verwenden Windows (Windows)
• Ich habe keinen meiner Softwarebenutzer gesehen, der es unter Linux (Linux) verwendet.

Ich habe darüber nachgedacht, https://github.com/1c7/Translate-Subtitle-File . zu drehen
dieses Projekt in ein ernsthaftes Projekt umwandeln (Geld aufladen & höhere Qualität haben (mehr Zeit darauf verwenden))
Also recherchiere ich jetzt

Dieses Tool würde vorerst hauptsächlich auf den chinesischen Markt abzielen. (Alle Schaltflächen und Texte wären auf Chinesisch)
i18n ist auf der Karte, aber nicht so bald

Ich hatte den Plan, eine i18n- und Yandex-Übersetzer-API zu erstellen, aber wegen des gleichen Problems habe ich das Projekt abgebrochen. Unter Linux haben die meisten neueren Benutzer kein Vertrauen in die Programme, von denen sie glauben, dass sie in Linux nicht existieren oder es keine Alternative gibt Wenn Sie also dieses Projekt erstellen und Ihre Benutzerziele nur die Medien übersetzen, können sie jede Linux-Disto oder meine bevorzugte Distribution deepin (chinesische Linux-Distribution) verwenden, hoffe das Beste für Sie und alle Linux-Benutzer.

Ihre API-Schlüssel und Ihr Geheimnis sollten niemals in einer veröffentlichten App enthalten sein. Stattdessen habe
sie auf Ihren APIs/Backend, und schützen Sie sie mit einer Art von
Authentifizierung/Drosselung. Lassen Sie dann Ihre App Ihre APIs nutzen.

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

@annymosse https://github.com/annymosse Ich habe gerade vergessen, Linux zu erwähnen,
nichts gegen Linux

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/electron/electron/issues/2570?email_source=notifications&email_token=ADCOXMFCSHRX3PZTE7GHKDTQPRLQRA5CNFSM4BODX2F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXZLOKTORDN5WWZ-5
oder abmelden
https://github.com/notifications/unsubscribe-auth/ADCOXMCKPUOMQPM3JKZP5J3QPRLQRANCNFSM4BODX2FQ
.

Es gibt eine Bibliothek namens bytenode, mit der Sie Ihre Javascript-Dateien in Binärdateien umwandeln können, damit niemand sie lesen kann.

Installieren Sie zuerst bytenode auf Ihrem Server und in Ihrem Ordner:

>npm i -g bytenode
>npm i bytenode

Erstellen Sie eine normale nodeJS-Datei mit dem folgenden Code darin. Stellen wir uns vor, wir nennen den folgenden Code: ok.js

>console.log('bytenode works!);
Kompilieren Sie dann Ihren Javascript-Code. Der Befehl erstellt eine .JSC-Datei mit demselben Namen wie Ihre Datei.

user<strong i="15">@machine</strong>:~$ bytenode -c ok.js
Dann rufen Sie in einer Hauptelektronen-JS-Datei Ihre Binärdatei auf, nennen wir sie test.js:

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

Speichern Sie es.

Dann rufen Sie test.js: node test.js auf, um es zu testen. Führen Sie eine "cat ok.jsc" aus, um zu sehen, dass es sich wirklich um eine Binärdatei handelt und niemand Ihren Code nicht sehen kann. Sie können Ihre ursprüngliche einfache Test-js-Datei an einen anderen Speicherort verschieben.
Ich habe es nicht mit Elektron getestet, aber ich denke, es würde funktionieren, oder?