ты прошерстил бы хоть рынок для начала

бля

вот ты опять начал

прошу прощения, конечно

всё уже придумано до тебя :)

но вопрос был не в этом

это просто пример

ну вот как защитить что то подобное в электроне?

написали же

и не раз вроде

никак?

если это уже обсуждали

и было найдено решение

кинь ссыль человеку

crypto-browserify

что задал этот вопрос

но это всё равно профанация

И я это понимаю, и ты это понимаешь. А человек пришел в чат, спросил насчет защиты. И тут включается вот этот режим ру-форумов, где человеку говорят какой он идиот, и все это не нужно, но не отвечают на вопрос.

Я это хочу донести

У меня всё

ну в js это не нужно

потому что всё равно расковыряют

вот тебе ссылочка. если в будущем будет такой вопрос, кидай ссыль https://t.me/electron_ru/4714

Вот, кстати, обсуждение на эту тему https://github.com/electron/electron/issues/2570

если у тебя хороший софт его не надо защищать

его и так будут покупать

инфа 100%

нормально js ты не защитишь

выносит алгоритмы в серверный код

а на фронте оставляй тупо отрисовку

вот тебе лучшая защита

выглядит как решение) спасиб ?

выносит алгоритмы в серверный код

А еще SSR и привет старый добрый web 1.0 )))

Эм?

Глупости какие то вы говорите

выносит алгоритмы в серверный код

кстати, хорошо бы посраться на эту тему ибо у меня есть немного сомнений связанных с этим утверждением

ну как бы а в чем проблема то?

ща, напишу кейс к обсуждению

есть сервер и тысяча электроновских приложений. на сервере сервис, который получает откудато данные и переводит их на язык устройств, которые через электронские приложения подключены на клиенте

нормально js ты не защитишь

Это не только Js. Все что угодно можно реверс инженерить.

ну типа да

вот этот самый "перевод "сообщений" на язык устройств" - где ему место? на сервере? или приложение должно получить сырые данные и перевести само? если клиентов 1к - сервис нормально справляется. если клиентов 1кк то возникает мысль освободить сервис от этой работы и переложить её на клиентов

или нет?

нет, клиенту отдают то, что можно "облизать". Все остальное должно правильно распределяться между серверам.

нет, клиенту отдают то, что можно "облизать". Все остальное должно правильно распределяться между серверам.

это утверждение без обоснования и, имхо, если ему следовать то мы вернёмся в web 1.0 мы переложили на клиент-сайд кучу всякой деятельности, почему не сделать это и при разработке приложения (предложенного выше)?

съэкономив этим кучу серверных ресурсов

это утверждение без обоснования и, имхо, если ему следовать то мы вернёмся в web 1.0 мы переложили на клиент-сайд кучу всякой деятельности, почему не сделать это и при разработке приложения (предложенного выше)?

логика объективна, при этом мое мнение - это вопрос универсальности. У всех устройства и возможности разные. Первая проблема на мой взгляд - это безопасность о которой говорили выше. Даже если клиент моего приложения реверснут, то все равно оближут палец, потому что вся магия моего GraphQL стоит на бэке

а ещё есть проблемы на твой взгляд?

больше нет, может кто то еще накинет

А вообще, основная нагрузка складывается из весомого трафика, который жрет собственно деньги. Передача текста, это не принципиальна. А клиент хранить у себя децентрализованно данные не сможет. Сейчас вспомнил сераил "Селиконовая долина", когда парень делал децентрализованный итернет. Это и будет лучшим решением для снижения нагрузки серверов или отказаться от них вовсе. Но пока я таких технологий не знаю.

не, давай в рамках моего примера ) 1кк клиентов, сервис должен выполнить по 1-2 задачке в минуту (перевод данных в язык устройства). есть 2 решения: серверное потребует дорогостоящей железки, инфраструктуры очередей обработки и прочего хардкора (куча денег уйдёт на разработку и обслуживание), делегируя это клиенту мы экономим ресурсы - плюс. минус, ага, возможно спиздят код.

я какбэ хотел сказать этим примером, что посчитав профит от каждого подхода вполне можно зайти в чятик и поинтересоваться возможно ли защитить код

да даже на этом примере. 1кк юзеров много файлов(картинок, документов), трафик видео к примеру. На клиента это не переложить, а все остальное вообще не принципиально.

не, давай в рамках моего примера ) 1кк клиентов, сервис должен выполнить по 1-2 задачке в минуту (перевод данных в язык устройства). есть 2 решения: серверное потребует дорогостоящей железки, инфраструктуры очередей обработки и прочего хардкора (куча денег уйдёт на разработку и обслуживание), делегируя это клиенту мы экономим ресурсы - плюс. минус, ага, возможно спиздят код.

Есть еще один минус, который видимо не так очевиден. Ты не можешь гарантировать валидность данных.

В случае сервера ты можешь быть уверен что операция успешно совершена. В случае клиента нет.

плюс у тебя получается "толстый" клиент где ты хранишь логику

плюс страдает кросплатформенность. Тебе надо дублировать код на различные платформы

В случае сервера ты можешь быть уверен что операция успешно совершена. В случае клиента нет.

вот этот аргумент норм

А может кто-нибудь знает варианты красивого отображения окна (на винде) без использования frame: false?

kiosk mode?

https://habrahabr.ru/company/ruvds/blog/335144/ не спама ради.

Как всегда, комментарии там - самое интересное

:D

Кстати, в тему безопасности, я периодически гоняю snyk для проверки npm-пакетов. Хотя там достаточно узкий набор уязвимостей, вроде.

А может кто-нибудь знает варианты красивого отображения окна (на винде) без использования frame: false?

пытаюсь разобраться, что происходит с окном, но на винде это сущий ад, так как при нормальном разрешении экрана: 1920:1080 - окно рендерится не в заданном разрешении и появляются контроллеры для пролистывания, и, если для высоты это еще можно списать на title bar то по ширине вообще дичь, если кто знает решение отпишитесь плиз

как же противно выглядит этот шрифт

пытаюсь разобраться, что происходит с окном, но на винде это сущий ад, так как при нормальном разрешении экрана: 1920:1080 - окно рендерится не в заданном разрешении и появляются контроллеры для пролистывания, и, если для высоты это еще можно списать на title bar то по ширине вообще дичь, если кто знает решение отпишитесь плиз

там есть параметр подгонять размер окна под контент

опять донат

причем непонятно зачем

на твичалертс очень гибкие настройки

остальные не нужны, по сути

лучше бы мультичат нормальный кто нибудь сделал

ребят, не гоните на парня. Он делает то, что ситает нужным, актуально это или нет, - ему покажет время

причем непонятно зачем

наш продукт работает с любой сриминговой платформой

твичалертс тоже с любой вроде работает

PS потом это был антихакатон яндекс денег)

донаталертс точно с любой

ни один нормальный стример не будет на яд деньги собирать

там же ональные ограничения

Кстати, если у кого при frame : false не работает какой либо элемент - чекайте что у него в стилях есть -webkit-app-region: no-drag;

electron v1.7.6 beta https://github.com/electron/electron/releases/tag/v1.7.6 Bug Fixes Fixed query string parsing in PDF Viewer #10008 (https://github.com/electron/electron/pull/10008) Fixed crash that occurred when loading URL in detached WebContents #9819 (https://github.com/electron/electron/pull/9819) Fixed issues around update permissions and non-admin users #10071 (https://github.com/electron/electron/pull/10071) Fixed chrome storage access scope to be shared across domains #9951 (https://github.com/electron/electron/pull/9951) Fixed content scripts matches #10075 (https://github.com/electron/electron/pull/10075) Fixed bug that returned an object instead of an empty string when reading from an empty asar file with 'utf8' option #10160 (https://github.com/electron/electron/pull/10160) Prevented async tasks from crashing after the Node environment is destroyed #10099 (https://github.com/electron/electron/pull/10099) Linux Fixed issue where opening menu would cause high CPU usage on certain Linux distributions #10070 (https://github.com/electron/electron/pull/10070) macOS Added code and domain as properties to error events emitted by autoUpdater module #10125 (https://github.com/electron/electron/pull/10125) Fixed bug where TouchBarScrubber.continuous was getting ignored #10133 (https://github.com/electron/electron/pull/10133) Windows Added labels for common accept file types #10015 (https://github.com/electron/electron/pull/10015) API Changes Added BrowserView.fromId() which returned the BrowserView with the given id #10039 (https://github.com/electron/electron/issues/10039) Added BrowserWindow.addExtension, BrowserWindow.removeExtension, BrowserWindow.getExtensions to add/remove/get Chrome extensions in an Electron app #9918 (https://github.com/electron/electron/pull/9918) macOS Added treatPackageAsDirectory flag to dialog.showOpenDialog, in order to treat packages, such as .app folders, as a directory instead of a file #9834 (https://github.com/electron/electron/pull/9834)

Холивар холиварный, кто что использует с Electron? react, angular?

Я angular, как-то исторически сложилось

Я angular, как-то исторически сложилось

А опыт с чем то другим был?)

Да, vue

Backbone

я на некоторых проектах react использовал, решил попробовать для сравнения что то еще

Да, vue

вот vue хотел

как он вообще?

как он вообще?

Отличный фреймворк

Норм

А кто react использует есть такие?

есть

А2 ибо на основном проекте А2