не, это быстро

а нет случаем где-то инсайда о включении 12 ноды в электрон?

5+ electron вроде тянет 12 ноду

А кто нибудь пробовал работать с mysql напрямую без api? 2 месяца назад пробовал, но пакет не обновляли, поэтому он не работал то-ли с протоколом то-ли с методом шифровки пользователя, не помню уже. Сейчас может дела получше обстоят

не, это быстро

У меня 40-50ms на JSON.parse строки в памяти размером 400Кб(немного промахнулся с размером массива, хотел 300)

ну вроде норм

Это относительно мало, но если учесть что подобные моменты имеют свойство накапливаться, везде немного, а в сумме приложение долго грузиться. Хотя вспомним продукты JetBrains и успокоимся)

Ну вот типа того. Тем более, далеко не у всех будет столько данных - чаще всего такое юзают, чтобы сохранить пару настроечек типа темы, токена какого-нить итд

У менея там хранится много данных, которые в идеале бы хранить на сервере, но мне лень

Ну вот типа того. Тем более, далеко не у всех будет столько данных - чаще всего такое юзают, чтобы сохранить пару настроечек типа темы, токена какого-нить итд

Для таких вещей норм, а вот если начнут туда картинки в base64

Не, у меня не картинки)

+, но все зависит от целей. т.к. эта штука ужасна для данных больше 1Кb в сумме

Вот именно поэтому, все зависит от целей)

Мужики, а такой вопрос. Я сейчас в локалсторедже сохраняю пару настроек пользователя. Но если юзер залогиниться под другой учеткой, то подтянуться применятся настройки первого. Как бы это зафиксить? Создавать для каждого юзера отдельный объект в сторедже не хочется. Что бы у второго юзера не было доступа к настройкам первого

Заносить айдишку юзера в настройки и чекать

А что бы не было доступа, закрываешь консоль в билде

Может просто чистить хранилище при авторизации? )

и при выходе

А можно ли как то исхитриться и прочитать весь локалсторедж? Девтулзов в билде нет

и при выходе

Тогда когда первый зайдет - а все настройки слетели

Тогда лучше хранить их не в localStorage, а в main-процессе и получать через сообщения

но всё равно это не гарантия, никак

гарантия - хранение на удаленном сервере и получение при авторизации

Тогда лучше хранить их не в localStorage, а в main-процессе и получать через сообщения

В мэйн процессе???

не в самом процессе, разумеется

короче хранить средствами ноды и передавать в renderer по запросу с клиента

гарантия - хранение на удаленном сервере и получение при авторизации

если приложение offline, то не сохранять, а так-то да, просто шлепай по REST на сайтик какой-нить, Авторизация туда-же, вот при первом логине и грузи все настройки пользователя, а если identity server свой, то еще можно и кучу настроек в claims для JWT запикуячить

Ок, спасибо, нужно будет обсудить на сколько сильно по поводу секьюрности упарываться

Что значит настройки юзера, для начала? Юзеры программы или юзеры операционки?

Если юзеры операционки, то и сторедж норм будет ) а если локальные проги, то можно пойти путем кодирования сохраненки ключом юзера, паролем, к примеру

Если юзеры операционки, то и сторедж норм будет ) а если локальные проги, то можно пойти путем кодирования сохраненки ключом юзера, паролем, к примеру

я думаю, что вооще тогда, можно запилить win32-api из npm и для других операционок похожее и вообще нативное хранилище дергать, то что за main, в OS

Да просто в хоме юзера хранить в файле... Это нормальная практика в принципе )

v8.0.0-nightly.20190821 https://github.com/electron/electron/releases/tag/v8.0.0-nightly.20190821 v8.0.0-nightly.20190821

Если юзеры операционки, то и сторедж норм будет ) а если локальные проги, то можно пойти путем кодирования сохраненки ключом юзера, паролем, к примеру

А это хороший вариант для оффлайн приложений

Спасибо за наводку

Спасибо за наводку

не за что, станет мало - шифруйте данные при изменении/сохранении хешем пароля юзера, а при запуске, соответственно, считывайте их расшифровывая тем же хешем...

не думаю, что найдется какой-то параноик, который попытается вскрыть это - ну, если только, там у вас не хранятся "ключи от квартиры с деньгами"

Но тогда придется хранить пароль, а это не кошерно

Но тогда придется хранить пароль, а это не кошерно

Я тоже так прочитал)

Но шифровать "хешом пароля" !== "паролем"

Но шифровать "хешом пароля" !== "паролем"

Сорян не внимательно прочитал

Но тогда придется хранить пароль, а это не кошерно

зачем ХРАНИТЬ пароль?

У меня пользователь не всегда вводит пароль когда открывает апп

Если поставил галку запомнить меня - я сохраняю токен и при следующем заходе уже не нужна регистрация

алгоритм: - запустилось приложение - юзер ввел логин+пасс - если авторизация успешная получаем хеш пароля - читаем и расшифровываем сохраненные данные в память .... юзер работает с данными в памяти ... - при сохранении шифруем данные хешем из шага 3 если в процессе юзер сменил пароль, то полчаем новый хеш...

токен, в некотором роде и есть хеш пароля, если что =)))

хотя... надо подумать, но ничего не мешает в токене первые 32 символа, например, отвести под md5 пароля...

хотя... надо подумать, но ничего не мешает в токене первые 32 символа, например, отвести под md5 пароля...

Зачем? Токена для шифрования достаточно.

если юзер разавторизуется, то чем шифровать? токеном? так при следующей авторизации токен другой будет и данные не расшифруешь

если юзер разавторизуется, то чем шифровать? токеном? так при следующей авторизации токен другой будет и данные не расшифруешь

А при следующей авторизации разве должны остаться эти данные?

Тогда не должны они храниться на клиенте.

Должны оставаться

я так понимаю, у человека приложение должно какие-то юзерские данные хранить локально =) это не кошерно, конечно, когда данные "секурные", но иногда альтернатив нет...

Тогда не должны они храниться на клиенте.

не все приложухи имеют клиент-серверную архитектуру =)))

О какой авторизации тогда идет речь)

особенно, если авторизация чья-то внешняя, типа OAuth2

Не там особо ничего такого нет. Просто не хоцца все по красоте сделать

особенно, если авторизация чья-то внешняя, типа OAuth2

OAuth2 тебе пароль не даст, а только токен

Который каждый раз будет разный

Естественно, авторизация только онлайн, но в принципе апом можно пользоваться и оффлайн

После логина

Естественно, авторизация только онлайн, но в принципе апом можно пользоваться и оффлайн

Ну так у тебя же токен хранится, его и юзай

Вот это мне и не особо нравится. Что токен в открытом виде в локал сторедже лежит

Ну а как иначе)

Какая секюрность на клиенте)

Который каждый раз будет разный

Не бузи ))) я образно...

Какая секюрность на клиенте)

Сделать мини шифровшик

А вообще, даже локальную авторизашку можно реализовать. От глубокого криптоанализа она не спасет, но "от дурака" закроет )

От особо настойчивых не спасет, но хоть в открытом виде не будет

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

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

Для снифера https нужен рут, а без рута одна каша будет.

Троян все порешает )))

Троян все порешает )))

Кей логер) Тут кто-то недавно интересовался этой темой)

От особо настойчивых не спасет, но хоть в открытом виде не будет

Давай так - ключевой вопрос. Под одним системным юзером операционки могут разные юзеры проги оказаться?

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

Давай так - ключевой вопрос. Под одним системным юзером операционки могут разные юзеры проги оказаться?

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

Речь о том, что при входе на комп Вася и Петя могут авторизоваться как один некий "оператор" или у каждого своя учетка?

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

Не, ну тут уже сорян. Это проблема юзера. Если ты знаешь что за твоим компом могут работать туева куча людей и ты не разлогиниваештся...

+ можно не ставить галку запомнить меня и

Если нет токена - прошу ввести логин/пароль

Без авторизации ни как