это уже зависит от того кто как напишет

Нативные модули хороши для трудоёмких вычислений, а в основном нужны какие-то мелкие. Ведь вызов нативного модуля сам по себе затратный. Как итог, считает быстрее, но вот чтобы начал считать и получить ответ нужно много времени

Ну-ну, ребята из Яндекса не умеют в хороший код?

Хм, интересно. Я сравнивал методы снятия скриншотов и нативные модули из robotjs были самые быстрые. Но да, мне важна скорость снятия скриншота, а не его передача обратно в код

это уже зависит от того кто как напишет

Так и там, и там под капотом нативные модули))

Ну в стандартном электроне тебе нужно из мейна послать сообщение в рендер и там снять скриншот, поэтому лучше в моем случае robotjs

Но к нативности отношение не имеет

Ты хочешь сказать, что хром скриншот рабочего стола, например, на JS делает?

Нет, я к тому, что мы отошли от изначального обсуждения

в доку загляни, ссылка выше

Ну-ну, ребята из Яндекса не умеют в хороший код?

Компания и качество кода вещи вообще не связанные

к тому же, в electron-builder есть функционал, чтобы можно было использовать что-то свое для шифрования

Использовал прогу prepros electron+react. Там можно взять премиум для того чтобы диалоговое окно не бесило. Труда не составило вскрыть и удалить вызов диалогового окна. Скорее всего, все электрон приложения уязвимы

Почему же. Прога как раз таки упаковывалась билдером. Но в доке не нашел я способы шифрования

"все электрон приложения уязвимы" Фраза ламера, который не умеет в низкоуровневое программирование и даже в гуглинг. Ведь все зачем-то добавляют лишнее слово "электрон", а нужно так: "все приложения уязвимы, а то что попало на компьютер юзеру, по умолчанию достояние юзера" А дальше уже дело в том, кто попадется, почему-то платные проги постоянно взламывают и выкладывают. Не важно C#/C++/Java всегда есть возможность что-то подправить. А дальше идут уже навороты, можно усложнять реверс, добавлять кучу прверок, etc. Но это не зависит от технологии, а только от необходимости и компетенции прогеров.

Ну хз конечно. Да, я не умею в низкоуровневое программирование, но вскрыть asar архив много знаний не нужно. А приложухи на c++, с# и т.д., вроде как архиватором не открываются и не правятся. Я к тому, что електрон не имеет защиты своих данных "исхоропки"

Справедливо. А хотелось бы, чтобы было всё из коробки. Собрал приложение и какой нибудь школьник его не взломал архиватором

Обжать это значит минифицировать? Ты это имеешь ввиду?

Справедливо. А хотелось бы, чтобы было всё из коробки. Собрал приложение и какой нибудь школьник его не взломал архиватором

Вопрос хайвмайнду. Никто не сталкивался на маке с проверкой включена ли аппа в список Security & Privacy -> Accessibility ?

Нет, найдешь ответит отпишись плиз))

Похоже, что не найду и нужно будет лепить костыли

Костыль оформленный в npm пакет, автоматически приобретает статус велосипеда)))

кто пробовал связку electron / nextjs / typescript?

Главное, чтобы несколько людей не использовали один токен одновременно

на какую например?

Главное, чтобы несколько людей не использовали один токен одновременно

Сделал эелектрон эпп. Теперь хочу, чтобы каждый человек использовал свой авторизационный токен(чтобы двое не использовали один токен). Как мне от этого защититься? Авторизация идет через рест(тупо отправляется токен а в ответ саксес). Есть вариант с сокетами, чтобы хотя бы двое одновременно не использовали, но не хочется держать постоянно коннекты.

Куча вариантов. Храни авторизацию токен на бэке и потом валидируй исходя из своих условий. У тебя условие очень размыто, чтобы конкретно что-то написать.

токен авторизации не хранится на беке, а генерируется на беке, и отдается клиенту, для использования своего АПИ, либо генерируется на стороннем сервере авторизации, и клиент забирает его самостоятельно, используя callback, так-же, на бек ничего не передается.

Это логично, но человеку нужно не стандартное поведение.

Главное, чтобы несколько людей не использовали один токен одновременно

Вопрос звучит супернепонятно Я не хочу два девайса с одним токеном, но при этом не хочу ограничивать юзера одним девайсом Наверное, стоит определиться)

Ребят, наверное мало инфы дал. Приложение электрон, оно само по себе не зависит от сервера и может работать без него. Сейчас нужно сделать так, чтобы это приложение можно было контролировать на уровне "рабочее/не рабочее". Решил просто генерить рандомный токен и на сервере просто хранить список "рабочих" токенов. Но в довесок нужна логика, которая говорила бы людям "не используй более одной учетной записи(токена) в один момент времени(погрешность 30-90 сек). Решил сделать так: при первом запуске авторизация(проверка на работоспособность токена) и соотношение мак адреса клиента с токеном. Далее пинг с передачей мака и токена, а на сервере проверяется, если соотношение мака с токеном не верное, то закрывается программа. А неверное соотношение может быть в случае, когда второй логин перебивает линковку мака с токеном, и соответственно первый уже невалидным получается