Electron: Apakah sumber benar-benar dilindungi dengan membangun aplikasi dengan Electron?

Tidak, sangat mudah untuk mendapatkan kode sumber Anda bahkan ketika Anda mengemasnya dalam arsip asar , mesin JavaScript V8 tidak pernah dirancang untuk menyembunyikan kode sumber. NW.js berhasil menyembunyikan satu file kode sumber sepenuhnya, tetapi dengan harga penurunan kinerja yang signifikan.

Jadi jika Anda benar-benar ingin melindungi kode sumber Anda, Anda harus menulisnya dalam C++ dan membuat modul Node asli.

Ada beberapa opsi, tetapi tingkat perlindungan yang mereka berikan dibatasi oleh alasan yang disebutkan @zcbenz :

• Anda dapat mengimplementasikan beberapa logika dekripsi sendiri, dalam addon node C++, tetapi mungkin masih dapat dipecahkan (misalnya men-debug program dan menyalin sumber setelah dekripsi tetapi sebelum evaluasi).
• Ada juga EncloseJS , yang mengklaim mengkompilasi kode Anda untuk node.js/io.js, sehingga mungkin bekerja dengan Electron.
• nw.js , yang merupakan proyek serupa, memiliki dukungan untuk snapshot v8 yang memberikan semacam perlindungan (lihat detailnya di sini ).

Perhatikan bahwa semua metode ini, akan dikenakan beberapa penalti kinerja.

@etiktin Saya juga mengalami ini.
Apakah mungkin untuk menerapkan kode node.js di addon C++ secara langsung?

@fritx , Node memiliki modul bernama vm yang dapat mengevaluasi kode. Saya kira Anda dapat menemukan cara untuk memanggilnya atau menggarisbawahi API C++ dari addon Anda dan menggunakannya untuk memuat kode Anda.
Ingatlah bahwa pengguna masih dapat membuka alat pengembang dan melihat skrip yang dimuat. Bahkan jika Anda berhasil memblokirnya menggunakan build Electron kustom dan addon memeriksa untuk melihat bahwa Electron build Anda tidak dirusak, pengguna masih dapat melihat kode Anda sebagai string di memori.

Kedengarannya bagus, lindungi sumbernya! :kunci:

Lalu saya punya pertanyaan, bagaimana aplikasi closed code electron seperti GitKraken, Whatsapp atau Slack dapat menyembunyikan kode tersebut?

@alexis57 saya punya pertanyaan yang sama; mungkin hanya elemen inspeksi yang dinonaktifkan atau semacamnya

Atau mungkin kode utama berasal dari pustaka C/C++ dan kemudian mereka menggunakan elektron hanya untuk GUI, tidak tahu ...

Ingin tahu bagaimana whatsapp dan slack melindungi kode sumber mereka juga

AFAIK itu hanya tidak terlindungi. Anda dapat mengekstrak app.asar mereka dan mengakses kode sumbernya. Untuk bagian aplikasi yang sensitif, Anda biasanya menulis add-on khusus dalam bahasa yang dikompilasi seperti C/C++, seperti yang disarankan di atas.

Bagaimana kita bisa mengkompilasi kode c++ di dalamnya?

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

@boeserwolf terima kasih! :)

Berlangganan

Itu juga mungkin dengan node-ffi . Elektron harus digunakan hanya untuk UI.

Mungkin perlu ditelusuri untuk menulis kode dalam C/C++ dan kemudian menggunakan alat seperti emscripten untuk mengubahnya menjadi perakitan web. Ini akan bekerja dengan baik dengan Chromium

Apa pun dapat dibongkar / tidak dikaburkan dengan usaha yang cukup. Menulis kode Anda dalam JavaScript dan memasukkannya ke dalam ASAR akan menjauhkan sebagian besar orang. Apakah ada alasan untuk melindungi kode yang tidak dicakup oleh hak cipta/lisensi?

2 sen saya di sini, NW sepertinya menyelesaikan masalah snapshot v8
https://nwjs.io/blog/js-src-protect-perf/

Saya menemukan artikel ini dari nwjs, "kode biner yang dikompilasi sekarang berjalan secepat kode sumber JS tanpa overhead kinerja" yang sebelumnya 30%, dan itu akan diaktifkan secara default pada rilis NW selanjutnya.

Sangat tertarik dengan ini, saya juga merah artikel @craftpip memberitahu kami dan sepertinya agak menarik. Jika elektron memiliki perlindungan kode (bahkan jika itu lebih lambat di sisi pengguna) ini akan membuat banyak pengembang merasa aman dan percaya diri saat menulis aplikasi mereka. Beri kesempatan tim elektron ;)

Ini terlalu tidak nyaman bagi pengembang. Menyerah dan beralih ke NW...

Saya ingin membagikan proyek node.js lain yang menggunakan perlindungan kode dengan cara yang sangat elegan: https://github.com/zeit/pkg

Mungkin ada harapan untuk perlindungan sumber di Electron?

Selain menggunakan C++ untuk beberapa bagian, Anda juga dapat mengecilkan dan _obfuscate_ sumber JavaScript Anda (misalnya menggunakan javascript-obfuscator ).

Pengecilan dan pengaburan bersama-sama akan _secara dramatis_ meningkatkan upaya yang diperlukan (dan dengan demikian _biaya_) untuk "mencuri" kode Anda, sering kali hingga merekayasa balik seluruh aplikasi Anda dari awal dengan mudah menjadi jauh lebih layak -- dan secara teknis tidak ada yang bisa Anda lakukan lakukan tentang rekayasa balik, bahkan jika Anda benar-benar asli (tidak ada, selain mencari hukum).

Jika Anda tidak khawatir menyembunyikan kode sumber Anda TAPI Anda ingin menyembunyikan rahasia Anda seperti:

• kredensial OAuth
• URL yang tidak dimaksudkan untuk diketahui publik (yaitu titik akhir API backend pribadi)
• Kredensial REST API
• Setiap Kunci dan Rahasia
• Kata sandi

Saya telah membuat layanan GRATIS untuk mengatasi masalah ini. Saya harus membuatnya karena saya membuat aplikasi elektron komersial dan khawatir kredensial saya dicuri.

Ia bekerja dengan membuat aplikasi pembantu lintas platform yang meluncurkan aplikasi elektron Anda yang sebenarnya JIKA aplikasi Anda belum dirusak. Setelah meluncurkan aplikasi, itu akan melewati kredensial Anda melalui variabel lingkungan.

Informasi lebih lanjut:

Pengantar:
https://medium.com/@rocketlaunhr.cloud/introducing -electron-vault-d09ade2c2020

Dokumentasi:
https://rocketlaunhr.github.io/electron-vault-docs/

@JohnWeisz

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

Bagaimana server server jarak jauh benar-benar mengetahui bahwa klien sebenarnya adalah Aplikasi Elektron Anda yang tidak berubah?
Itulah masalah yang saya coba selesaikan.

Jika Anda menggunakan OAuth dengan jenis hibah Client Credentials , maka client_secret masih dimasukkan ke dalam aplikasi Anda dan siapa pun secara teori dapat membacanya. Dengan kode sumber Electron 100% terbuka dan tersedia, mudah untuk mencari string yang muncul "menarik".

Tidak ada cara yang 100% terbukti bodoh untuk menyelesaikan masalah, tetapi saya yakin solusi saya adalah peningkatan yang pasti.

Saya percaya ini mungkin dengan membangun aplikasi JS Anda dengan webpack atau kerangka SPA seperti angular2/4/6 atau vuejs2. ini mengecilkan kode Anda dan ketelitiannya meskipun seseorang mengekstrak file asar, mungkin sulit bagi mereka untuk membaca kode Anda

Saya pikir masalahnya seharusnya tidak hanya fokus pada enkripsi yang sebenarnya. Tetapi pada kenyataannya, tidak ada aplikasi/pengguna lain yang merusak kode sumber klien.

Dengan memiliki arsip asar yang ditandatangani atau biner serupa dari mana kode sumber dimuat akan memungkinkan elektron untuk memeriksa integritas file. Karena pemeriksaan integritas dapat diintegrasikan dalam biner elektron itu sendiri, tidak akan ada kelebihan dalam kode javascript. Pada dasarnya saat membangun elektron bisa mendapatkan flag --include-integrity-check, jika tidak, cara normal untuk melakukannya dikompilasi.

@tulpn

Karena pemeriksaan integritas dapat diintegrasikan dalam biner elektron itu sendiri, tidak akan ada ...

-- maka itu hanya masalah mengekstraksi pemeriksaan integritas atau enkripsi/dekripsi yang dilakukan Elektron, dan Anda memiliki kode sumbernya. Saya yakin kebingungan adalah satu-satunya pendekatan yang dapat Anda ambil di sini (baik itu minifikasi, minifikasi+kebingungan, atau kompilasi kode asli).

Itu, atau memindahkan beberapa kode aplikasi Anda ke layanan jarak jauh (dengan otentikasi jika Anda memerlukan keamanan).

Anda dapat mengenkripsi data Anda dan mendekripsinya saat runtime dan memuatnya langsung ke variabel seperti token atau data sensitif apa pun, tetapi jika Anda berbicara tentang mengenkripsi seluruh file javascript maka itu akan mengurangi kinerja. Anda dapat mencoba Node C++ Addons

Seperti yang dikatakan nodejs:

Node.js Addons adalah objek bersama yang terhubung secara dinamis, ditulis dalam C++, yang dapat dimuat ke Node.js menggunakan fungsi require(), dan digunakan seolah-olah mereka adalah modul Node.js biasa. Mereka digunakan terutama untuk menyediakan antarmuka antara JavaScript yang berjalan di Node.js dan pustaka C/C++.

Pada dasarnya itu mengkompilasi kode Anda menjadi biner dan dengan cara itu Anda dapat mengabstraksi kode dan kinerja Anda akan jauh lebih cepat dan Anda dapat menyembunyikan kode Anda sampai batas tertentu.

Tidak, sangat mudah untuk mendapatkan kode sumber Anda bahkan ketika Anda mengemasnya dalam arsip asar , mesin JavaScript V8 tidak pernah dirancang untuk menyembunyikan kode sumber. NW.js berhasil menyembunyikan satu file kode sumber sepenuhnya, tetapi dengan harga penurunan kinerja yang signifikan.

Jadi jika Anda benar-benar ingin melindungi kode sumber Anda, Anda harus menulisnya dalam C++ dan membuat modul Node asli.

bagaimana saya bisa menonaktifkan devtools dari c++ addons dan bagaimana saya bisa mengakses semua API elektron dari c++ addons dan apakah ada rencana untuk mengemas aplikasi tanpa devtool ini dapat membantu untuk mencegah peretasan dan dengan ukuran aplikasi yang lebih kecil ( @ zcbenz )

Kami semua bosan dengan kode sumber kami yang dipublikasikan. Saya pindah ke nw

@ahmtcn123 Bagaimana komentar Anda membantu memecahkan masalah ini?

Anda ingin membangun aplikasi dengan teknisi web yang pada dasarnya memiliki kode sumber publik, jadi berhentilah dengan sikap itu.

• Anda dapat berkontribusi ke Electron untuk mengatasi masalah ini
• Menulis modul C++
• Perkecil / obfuscate / potong kode Anda (dan jangan lupa untuk menonaktifkan peta sumber)
• Anda dapat pindah ke teknologi serupa lainnya (seperti nw.js), atau Anda dapat menggunakan teknologi asli
• Beberapa solusi lain telah dibagikan di sini, Anda dapat menukar kebingungan untuk kinerja (yang merupakan pilihan yang tidak begitu jelas untuk dibuat ketika kita sudah mengetahui kinerja/konsumsi sumber daya Electron)

Bersulang!

_edit: tetap down-voting guys_

Mengapa tidak mendukung v8snapshot?

Saya mengerti kami tidak dapat sepenuhnya melindungi kode sumber. tetapi cara lain dapat membuat layanan web menggunakan teknologi kompilasi asli (seperti golang) untuk melindungi kode logika dan panggilan dari UI elektron melalui localhost.

kata terakhir

NW

kenapa masalah ini ditutup?

Karena menyembunyikan kode sumber selalu menjadi topik kontroversial karena dianggap Keamanan melalui ketidakjelasan metode yang sangat buruk untuk melindungi kode Anda.

Jika Anda menginginkan perlindungan, gunakan metode yang lebih standar, seperti otentikasi untuk melakukan tindakan kritis, enkripsi, dan sebagainya.

Hormat kami, Anda dapat menulis aplikasi Anda di C dan mendistribusikan binari, kami akan tetap mendapatkan kode sumber Anda.

PD: Anda dapat mengakses kode sumber anak laki-laki besar (web whatsapp, slack, tim, vscode) dan tidak ada dari mereka yang peduli, mungkin Anda melakukan sesuatu yang salah.

""" PD: Anda dapat mengakses kode sumber anak laki-laki besar (web whatsapp, slack, tim, vscode) dan tidak ada yang peduli tentang itu, mungkin Anda melakukan sesuatu yang salah."""

Seseorang hampir tidak bisa membuat argumen yang lebih bodoh.

Menjual perangkat lunak tanpa menginginkannya direkayasa ulang dan digunakan dengan cara yang tidak seharusnya tidak normal, sebenarnya ada undang-undang yang tepat untuk itu, yang tidak menghentikan pengguna untuk tetap melakukannya.

@kidandcat

Hormat kami, Anda dapat menulis aplikasi Anda di C dan mendistribusikan binari, kami akan tetap mendapatkan kode sumber Anda.

Ayo, dapatkan sumber dari semua aplikasi terlaris seperti Microsoft word, Photoshop, atau bahkan game terlaris. Apakah Anda seorang miliarder dan saya tidak menyadarinya atau apa?

Tidak lol, saya bukan miliarder karena memiliki kode sumber dari program-program itu tidak berguna, apa yang akan Anda lakukan dengan itu?

Teman-teman tolong, ada banyak orang di utas ini yang mendapat pemberitahuan untuk setiap komentar, harap tetap konstruktif.

Untuk meringkas mengapa, menurut saya, harus berurusan dengan kekhasan kode sumber JavaScript bukanlah pemecah masalah dalam banyak kasus:

• Banyak contoh aplikasi/layanan yang tercantum di sini sebagian besar didorong oleh _traction_; ambil Twitter misalnya, ini bukan misteri bagaimana ia bekerja secara internal, tetapi bahkan dengan menyalin dan mereproduksinya secara keseluruhan tidak akan membawa Anda ke mana pun tanpa lalu lintas, iklan, merek, infrastruktur pendukung, dll.
• Kebingungan yang tepat membuatnya sangat, _prohibitive_ sulit untuk mengakses kode sumber dengan cara apa pun yang berarti, ke titik di mana menjadi jauh lebih layak untuk hanya mengamati perilaku aplikasi itu sendiri dan merekayasa baliknya berdasarkan itu, tanpa bergantung pada yang asli kode sumber -- seperti dalam kasus misalnya C++
• Mencuri ide dan/atau solusi dari aplikasi yang dilindungi undang-undang hak cipta adalah masalah hukum, bukan masalah teknis, dan dengan demikian, melindungi implementasi adalah urusan hukum, terlepas dari tingkat perlindungan yang diterapkan; perusahaan Cina yang mencurigakan akan mencuri logo dan aplikasi Anda tanpa masalah, terlepas dari apakah itu ditulis dalam JavaScript atau Majelis
• Selain itu, Anda dapat menyertakan kode C++ dalam aplikasi Anda jika Anda tidak yakin tentang kebingungan, atau Anda dapat memindahkan kode ke layanan jarak jauh yang, tidak seperti yang lainnya (termasuk C++), sangat terlindungi dari pemeriksaan langsung (bukan dari rekayasa balik meskipun)

@JohnWeisz mengatakan banyak hal yang sangat masuk akal. Saya juga akan menambahkan bahwa jika itu tidak cukup untuk Anda, Anda dapat menggunakan WebAssembly hari ini. Dalam hal melindungi kode sumber, itu seharusnya cukup bagus.

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

@kidandcat Benarkah?" Hormat kami, Anda dapat menulis aplikasi Anda di C dan mendistribusikan binari, kami akan tetap mendapatkan kode sumber Anda."

Saya mencari di google, sepertinya tidak mungkin untuk mendapatkan kode sumber dari binari yang dikompilasi dari C/C++. Paling-paling, kita bisa mendapatkan pernyataan perakitan.

Saya sedang mengembangkan perangkat lunak desktop windows komersial. Logika kode adalah kompetensi utama. Logika ini harus berjalan di sisi klien tetapi saya tidak ingin pesaing saya mendapatkannya. Jadi perlindungan kode adalah pemecah kesepakatan dalam kasus saya.

@z1988hf

sepertinya tidak mungkin untuk mendapatkan kode sumber dari binari yang dikompilasi dari C/C++. Paling-paling, kita bisa mendapatkan pernyataan perakitan

Artinya, Anda dapat merekayasa balik kode sumber asli, atau sesuatu yang setara, hanya saja biasanya sangat sulit dan karenanya mahal. Hal yang sama dapat dikatakan tentang kode yang dikaburkan.

@kidandcat Benarkah?" Hormat kami, Anda dapat menulis aplikasi Anda di C dan mendistribusikan binari, kami akan tetap mendapatkan kode sumber Anda."

Saya mencari di google, sepertinya tidak mungkin untuk mendapatkan kode sumber dari binari yang dikompilasi dari C/C++. Paling-paling, kita bisa mendapatkan pernyataan perakitan.

Saya sedang mengembangkan perangkat lunak desktop windows komersial. Logika kode adalah kompetensi utama. Logika ini harus berjalan di sisi klien tetapi saya tidak ingin pesaing saya mendapatkannya. Jadi perlindungan kode adalah pemecah kesepakatan dalam kasus saya.

Perakitan juga adalah pasangan kode, logika Anda akan ada di sana. Anda perlu melakukan lebih banyak hal untuk melindungi kode Anda daripada hanya mengompilasinya. (tetapi seperti yang dikatakan @JohnWeisz , perangkat lunak rekayasa balik sangat mahal, jadi Anda tidak perlu khawatir jika pesaing Anda tidak tertarik untuk membuang beberapa ribu dolar hanya untuk mencobanya)

Bagi mereka yang mereferensikan aplikasi seperti Slack sebagai tidak peduli tentang perlindungan kode sumber, itu bukan perbandingan terbaik untuk semua aplikasi. Slack adalah layanan yang hidup online dan aplikasi elektron mereka hanyalah cangkang untuk menampilkan aplikasi web mereka. Mayoritas saus rahasia aplikasi seperti slack hidup di server web.

Bagi mereka yang mereferensikan aplikasi seperti Slack sebagai tidak peduli tentang perlindungan kode sumber, itu bukan perbandingan terbaik untuk semua aplikasi. Slack adalah layanan yang hidup online dan aplikasi elektron mereka hanyalah cangkang untuk menampilkan aplikasi web mereka. Mayoritas saus rahasia aplikasi seperti slack hidup di server web.

@Kesukaanmu
bagaimana dengan spotify !!!, kami tahu apa yang Anda maksud tetapi bagaimana dengan aplikasi offline??

Saus rahasia @annymosse Spotify bukanlah aplikasi mereka. Jika seseorang mencuri sumber aplikasi Spotify, itu tidak masalah. Aplikasi ini cukup baik. Alasan sebenarnya orang menggunakan dan membayar Spotify adalah karena penawaran konten dan kenyamanan streaming musik. Ada beberapa detail UX yang mungkin lebih disukai daripada alternatif oleh banyak pelanggan Spotify tetapi pesaing tidak benar-benar membutuhkan kode sumber untuk menyalinnya. Selain itu, saya belum mencoba untuk melihat kode sumber Spotify, tetapi saya membayangkan mereka memiliki semacam perlindungan yang dibangun ke dalam aplikasi di suatu tempat. Kemungkinan beberapa kebingungan yang solid serta add-on C asli. Saya pikir ini akan menjadi persyaratan bagi mereka karena DRM.

@favorit Anda lihat saja sumbernya, ingatlah terkadang kami tidak menyembunyikan sumber kami untuk aplikasi komersial, kami melakukan itu untuk mencegah layanan kami jauh dari peretas yang mereka dapatkan beberapa garis lemah, bagaimanapun kami hanya membutuhkan fitur ini jika ada kemampuan untuk melakukan itu, setidaknya beberapa metode untuk melewati asar files dan package.json dan *.js

Saya tidak menentang perlindungan kode sumber, tetapi bahwa Slack dan Spotify mungkin bukan perbandingan terbaik untuk apa yang dilakukan kebanyakan orang dengan elektron. Selain itu, jika perlindungan kode sumber sangat penting untuk produk Anda, mungkin elektron bukan yang paling cocok saat ini.

Dan untuk lebih jelasnya, saya mendukung perlindungan kode sumber dari beberapa jenis yang datang ke elektron.

Saya membutuhkan perlindungan kode sumber. Biarkan saya memberikan kasus penggunaan di sini:

Saya mencoba membangun basis perangkat lunak terjemahan di Google Translate API

Pengguna menyeret file subtitle .srt/.ass ke dalam perangkat lunak, dan perangkat lunak akan menggunakan Google Translate API untuk menerjemahkan setiap baris.

Contoh

Pengguna mengunduh 1 video dan 1 subtitle bahasa Inggris.
Sekarang mereka dapat menggunakan perangkat lunak ini untuk menerjemahkan subtitle bahasa Inggris ini
ke dalam bahasa Cina atau bahasa lainnya.
Sehingga mereka dapat memahami isinya.

Masalah

Jika kode sumber mudah didapat.
rupanya penyerang bisa mendapatkan kunci & rahasia API saya. dan menyalahgunakannya.
dan saya akan mendapatkan tagihan besar dari Google ($500? $1000? lebih?)

Pembaruan Cepat (2020-Maret-29)

Saya menggunakan Vue.js + Webpack dengan Electron.js
jadi semua kode akan mendapatkan minify, jadi itu bukan masalah lagi

@1c7

Yah, mungkin Anda harus menggunakan beberapa perlindungan eksternal untuk mencapai ini. Saya dapat dengan mudah mengambil kunci API Anda dari perangkat lunak C++ juga, tidak masalah. Jadi ini sebenarnya bukan masalah khusus elektron.

@lvkins oh begitu. Saya tidak tahu perangkat lunak C++ memiliki masalah ini juga. Saya tidak asing dengan bahasa ini.
Terima kasih untuk tipsnya!

Pada dasarnya setiap bahasa pemrograman dapat direkayasa ulang. Itu selalu menjadi perhatian besar. Benar bahwa perlindungan apa pun lebih baik daripada tidak ada perlindungan, tetapi tetap saja; kita perlu melakukan upaya ekstra untuk melindungi data sensitif, apa pun bahasa pemrogramannya. Dalam kasus Anda, Anda mungkin harus menggunakan pustaka C++, menambahkan garam tambahan di atasnya dan menautkannya ke node.js Anda, Itu harus dilakukan.

@lvkins Anda membalas saya kan?
Terima kasih untuk sarannya. Saya akan menyelidiki ini.

Saya ingin menggunakan Electron.js karena saya ingin software terjemahan ini bisa berjalan di Mac & Windows.

Sepertinya Electron.js + beberapa C++ dapat melindungi kunci & rahasia API saya

Terima kasih @lvkins

@1c7 Memang

Mulai di sini: https://nodejs.org/api/addons.html

Jika kekurangan total elektron membuat Anda khawatir, Anda juga bisa mencoba NW.js.

Semoga beruntung!

@1c7 dan mengapa tidak Linux?!! saya pikir itu basis kode yang sama untuk semua platform kan??!

@annymosse Saya hanya lupa menyebutkan Linux, tidak ada yang menentang Linux.

FYI:

• Saya menggunakan Macbook Pro 2017 15 inci (Mac)
• Sebagian besar pengguna saya menggunakan Windows (Windows)
• Saya belum melihat pengguna perangkat lunak saya menggunakannya di Linux (Linux)

Saya sedang berpikir untuk mengubah https://github.com/1c7/Translate-Subtitle-File
proyek ini menjadi proyek yang serius (membebankan uang & memiliki kualitas lebih tinggi (menghabiskan lebih banyak waktu untuk itu))
jadi saya sedang melakukan penelitian saya sekarang

Alat ini sebagian besar akan menargetkan pasar China untuk saat ini. (semua tombol dan teks akan dalam bahasa Cina)
i18n ada di peta tetapi tidak akan segera

saya punya rencana untuk membuat API penerjemah i18n & Yandex tetapi karena masalah yang sama saya membatalkan proyek, kemudian di Linux sebagian besar pengguna baru tidak yakin dengan program yang menurut mereka tidak ada di Linux atau tidak ada alternatif jadi jika Anda membuat proyek itu dan target pengguna Anda hanya menerjemahkan media, mereka dapat menggunakan disto Linux apa pun atau deepin distribusi pilihan saya (distro Linux Cina), semoga yang terbaik untuk Anda dan semua pengguna Linux.

Kunci & rahasia API Anda tidak boleh ada dalam aplikasi yang dipublikasikan. Alih-alih memiliki
mereka di API/backend Anda, dan lindungi mereka dengan beberapa jenis
otentikasi/pembatasan. Kemudian minta aplikasi Anda menggunakan API Anda.

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

@annymosse https://github.com/annymosse Saya baru saja lupa menyebutkan Linux,
tidak ada yang menentang Linux

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/electron/electron/issues/2570?email_source=notifications&email_token=ADCOXMFCSHRX3PZTE7GHKDTQPRLQRA5CNFSM4BODX2F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX15Z#ZLOBYJ5WSTIHJKTOR97
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ADCOXMCKPUOMQPM3JKZP5J3QPRLQRANCNFSM4BODX2FQ
.

Ada perpustakaan bernama byteode yang memungkinkan Anda mengubah file Javascript menjadi file biner sehingga tidak ada yang bisa membacanya.

Pertama instal byteode di server Anda dan di folder Anda:

>npm i -g bytenode
>npm i bytenode

Buat file nodeJS normal dengan kode berikut di dalamnya. Mari kita bayangkan kita memberi nama kode berikut: ok.js

>console.log('bytenode works!);
Kemudian, kompilasi kode javascript Anda. Perintah akan membuat file .JSC dengan nama yang sama dengan file Anda.

user<strong i="15">@machine</strong>:~$ bytenode -c ok.js
Kemudian, dalam file JS elektron utama, Anda akan memanggil biner Anda, sebut saja test.js:

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

Simpan itu.

Kemudian, Anda akan memanggil test.js: node test.js untuk mengujinya. Lakukan "cat ok.jsc" untuk melihat bahwa itu benar-benar biner dan tidak ada yang bisa melihat kode Anda. Anda dapat memindahkan file js pengujian polos asli Anda ke lokasi lain.
Saya tidak mengujinya dari elektron tetapi saya kira itu akan berhasil, bukan?