Как это относится к теме чата?

Болью поделился))

const readdir = util.promisify(fs.readdir) readdir(path) .then(files => {create a file}) .catch(e => {}) если такой папки нет, то получаю ошибку е, а мне нужно создать такую папку fs.mkdir(done => {create a file}) эту логику в catch что ли пихать?

Fsextra пакет. Там есть ensureDir или как то так. Если нет папки, создаёт

Болью поделился))

Это тематический чат по ноде, а не для светских бесед, следующий раз ро

https://github.com/jprichardson/node-fs-extra/blob/master/docs/ensureDir.md

10 нода использует все ядра, т.е больше нет смысла в кластеризации ?

10 нода использует все ядра, т.е больше нет смысла в кластеризации ?

это откуда такие выводы?

ошибочное предположение. 1 процесс работает в границах 1 ядра (как его видит ОС)

@reskwer вопрос. а откуда такой вывод да

Ребят, всем привет, а может кто то подсказать как решается такая ситуация обычно?: есть сайт на котором можно покупать страховки без регистрации (вводим емейл и контактные данные, потом оплачиваем), потом можем купить новую, ввести тот же емейл, но уже другие контактные данные, а потом зарегистрироваться с этим емейлом и увидеть список страховок которые купили пока у меня в голове для этого нужно создать 3 юзера с одинаковым email и возможноразными контактными данными. Наверняка есть какой то устоявшийся подход к такого рода задачам, может подскажете хотябы что гуглить, вообще уже не соображаю >.<

сделать подтверждение мыла

Ребят, кто-то работал с Node.js + ZohoCRM? ?

Ччгрч

сделать подтверждение мыла

нельзя, требование заказчика нужно чтобы можно было быстро ввести данные и распрощаться с деньгами

нельзя, требование заказчика нужно чтобы можно было быстро ввести данные и распрощаться с деньгами

Тогда никак

нельзя, требование заказчика нужно чтобы можно было быстро ввести данные и распрощаться с деньгами

норм так, ввёл имейл, отдал денег и забыл

Ну вот так работают страховые сайты, вводишь данные, платишь бабки и получаешь страховку и как то же они это делают )

и тут нужно еще один сделать, а "никак")

Сделай чтобы доступ в личный кабинет только по подтверждению Указал чужой - сам виноват

доступ - да, так и будет а вот при оформлении не понятно что делать наверно просто в данных страховки и юзера будут дублироваться данные типа ФИО и номера телефона, а по email будет связываться с аккаунтом

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

данные — аттрибут покупки, а не юзера.

оу, спасибо ) познавательно

там просто ФИО можно ввести и при реге, и при покупке

"пустой пароль" это абстрактно. потому что юзеры без пароля — здец.

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

ну вставляй первые какие встретятся, вторые уже не обновляй.

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

думай шире.

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

@uldin , Привет, я насчет тех пунктов обменных решили путем сохранения в бд изминений %, тогда просто по брейкпойнтам считаю прибыль

@uldin , Привет, я насчет тех пунктов обменных решили путем сохранения в бд изминений %, тогда просто по брейкпойнтам считаю прибыль

привет. круто. надеюсь мои изречения все равно чем-то помогли.

привет. круто. надеюсь мои изречения все равно чем-то помогли.

Я пробовал осмыслить, но делить на дни сложнее оказалось)

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

Подскажите, при деструктуризации аргументов, можно ли как-то деструктуризоваться еще уровнем выше? Допустим приходит обьект {item: {id:"ddd"}}, могу как-то сразу получить id?

const { item: { id } } = obj;

Подскажите, при деструктуризации аргументов, можно ли как-то деструктуризоваться еще уровнем выше? Допустим приходит обьект {item: {id:"ddd"}}, могу как-то сразу получить id?

Можешь даже элементы массива получить

{ arr: [a,b,c] } Вроде так

const { item: { id } } = obj;

спасибо большое??

Ребят, всем привет, а может кто то подсказать как решается такая ситуация обычно?: есть сайт на котором можно покупать страховки без регистрации (вводим емейл и контактные данные, потом оплачиваем), потом можем купить новую, ввести тот же емейл, но уже другие контактные данные, а потом зарегистрироваться с этим емейлом и увидеть список страховок которые купили пока у меня в голове для этого нужно создать 3 юзера с одинаковым email и возможноразными контактными данными. Наверняка есть какой то устоявшийся подход к такого рода задачам, может подскажете хотябы что гуглить, вообще уже не соображаю >.<

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

Здравствуйте Кто-нибудь работал с solr-node? Как я могу запустить его?

У меня такой вопрос про IE11. Создаю новое изображение new Image() назначаю ему src и IE11 фризится на пару секунд. Было у кого нибудь такое? Другие браузеры нормально работают

У меня такой вопрос про IE11. Создаю новое изображение new Image() назначаю ему src и IE11 фризится на пару секунд. Было у кого нибудь такое? Другие браузеры нормально работают

@js_ru

@js_ru

Спасибо

посоветуйте graphql + websocket на ноде, может есть примерчик на github

посоветуйте graphql + websocket на ноде, может есть примерчик на github

https://github.com/rse/graphql-io-client ?

https://github.com/rse/graphql-io-client ?

так это клиент, мне серверную часть нужно

Всем привет! Подскажите, почему bcrypt на один и тот же стринг генерирует разный хеш при каждом проходе?

Сам себе ответил, не актуально

Сам себе ответил, не актуально

То есть мы так и не узнаем, почему разный хэш у одного стринга при каждом проходе??? Это не ты придумал LOST?

То есть мы так и не узнаем, почему разный хэш у одного стринга при каждом проходе??? Это не ты придумал LOST?

Bcrypt generates a random 128-bit salt during hashing. This salt becomes part of the hash, hence we always get a different hash value for the same input string. The random salt is actually used to deter brute-force attacks.

А как получить соль?

она сама генерится под капотом каждый раз

Не, ну я получил результат. Там всё в одну строку - хэш + соль?

а если я хочу сравнить с паролем из базы и соль мне уже известна? Странная функция какая-то

да, просто строка на выходе

там ф-ция есть, в которую ты кормишь стринг (пароль) + хеш из базы и она проверяет, был ли этот хеш получен от той же стринги

ERROR: S client not available

но сравнить просто строки === не выйдет

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

там ф-ция есть, в которую ты кормишь стринг (пароль) + хеш из базы и она проверяет, был ли этот хеш получен от той же стринги

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

мда

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

есс кормишь хеш + стринг и получаешь тру/фолс

Вот это технологии, однако! То-то на меня мужик на собеседовании так смотрел дико, когда я предлагал ему соль в БД хранить

Как по это всё нагуглить? По слову bcrypt?

какие еще технологии, щас бы без соли чекать хеш

Как по это всё нагуглить? По слову bcrypt?

да несколько npm пакетов есть, там довольно прозрачно описано

какие еще технологии, щас бы без соли чекать хеш

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

А зачем соли хранить хранить в бд?:)

А зачем соли хранить хранить в бд?:)

ну так раньше делали вроде

ну так раньше делали вроде

?помойму никогда так не делали, да и не безопасно это

ну так раньше делали вроде

те, кто так поступал и сейчас делают

?помойму никогда так не делали, да и не безопасно это

согласен. поэтому bcrypt неплох Ну а где бы его еще хранить было?

согласен. поэтому bcrypt неплох Ну а где бы его еще хранить было?

?в .env файлах например, ну или гду у вас конфиги

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

Он в этой строке как раз и хранит конкатенированные хэш + соль.

Он в этой строке как раз и хранит конкатенированные хэш + соль.

То есть всё-таки соль попадает в БД?

$2y$13$YUUgrko03UmNU/fe6gNcO.Hka4lrdRlkq0iJ5d4bv4fK.sKS.6jXu 2y - версия алгоритма bcrypt 13 - cost. Стоимость вычислений. 2^13 итераций функции формирования ключа Оставшееся — конкатенированные соль и хеш, закодированные через base64 с немного нестандартным набором символов. Первые 22 символа — 16 байт соли. Оставшееся — хеш

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

строка хеша, уже содержит хеш + соль. кидая ей исходную строку, он с помощью соли приводит к хешу и сравнивает

Соль и не должна быть секретной.

строка хеша, уже содержит хеш + соль. кидая ей исходную строку, он с помощью соли приводит к хешу и сравнивает

Это уже гораздо логичнее звучит. В таком случае не понял, почему тут челики писали что небезопасно хранить соль в БД

Она защищает от составления радужных таблиц. Чтобы нельзя было заранее сформировать таблицу хэшей.

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

Это уже гораздо логичнее звучит. В таком случае не понял, почему тут челики писали что небезопасно хранить соль в БД

Соль != зашифрованный пароль под солью :)

?

Соль != зашифрованный пароль под солью :)

Спасибо, кэп ?