не проще ли какой-нибудь ORM подтянуть и не писать руками запросы, тем более такие простые

не проще ли какой-нибудь ORM подтянуть и не писать руками запросы, тем более такие простые

+

Тебе придётся или чейнить запросы и поменять forEach на for of который поддерживает async/await

не проще ли какой-нибудь ORM подтянуть и не писать руками запросы, тем более такие простые

может и проще. Дайте ссылку куда копать хоть? Я просто с нодой только столкнулся. Жизнь заставила)

может и проще. Дайте ссылку куда копать хоть? Я просто с нодой только столкнулся. Жизнь заставила)

https://ru.wikipedia.org/wiki/ORM https://medium.freecodecamp.org/a-comparison-of-the-top-orms-for-2018-19c4feeaa5f

Тебе придётся или чейнить запросы и поменять forEach на for of который поддерживает async/await

цикл for in нужно оборачивать еще в одну функцию получается? или куда async / await дописывать в данном случае?

У меня async функция в одном модуле, в которой 3 await и один setInterval

У тебя там рекурсии нету?

https://ru.wikipedia.org/wiki/ORM https://medium.freecodecamp.org/a-comparison-of-the-top-orms-for-2018-19c4feeaa5f

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

цикл for in нужно оборачивать еще в одну функцию получается? или куда async / await дописывать в данном случае?

For of

цикл for in нужно оборачивать еще в одну функцию получается? или куда async / await дописывать в данном случае?

async function doStuff() { // ... for (let el of elements) el.price = await query('SELECT ...'); // ... }

о. спасибо. буду пробовать

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

А посоветуйте как с в express и jsonwebtoken легко и правильно рефрешить токен? лучше не с отдельным роутом который по старому токену отдает новый. А с одной универсальной миддварей авторизации. Думаю нужна такая логика: - Если токен не устарел вернуть юзера - Если токен устарел, но пригоден для рефреша, то рефрешить вернуть юзера и новый токен - Если токен устарел полностью включая REFRESH_LIFE_TIME или не валиден, не существует.. и далее передать просто user равный null и сообщение что не удалось авторизовать... но не ошибку. Так вообще делают? я видел похожие примеры, но до конца что то их не догоняю... ну и не будет ли такой алгоритм проблемой с безопасностью?

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

я вот думаю, может промисами как-то можно. Типа с помощью Promise.all

Вот один из примеров jwt.verify(token, 'secret', function(err, decoded) { if (err) { // it should if (err.name == 'Error' && err.message == 'jwt expired') { // paranoid mode // if decoded payloads needed : old_payloads = jwt.decode(token); // now you can check user, permissions, .... and serve a new token new_token = jwt.sign({ iss: old_payloads.iss}, 'secret', {expiresInMinutes: 60}); res.json({token:new_token}); } } { iss: old_payloads.iss} вот это я не очень понимаю.. почему только это.. а где остальной payload... и еще достаточно ли этого? просто расшифровываем просроченный токен и складываем его payload в новый токен и все? видел другие примеры когда рефреш токен и access token генеряться сразу в момент логина оба. Отдаються клиенту.. еще refresh token записывается в redis Но возможно это уже овер... Как Вы делаете в своих приложениях? Мне еще не хочеться фронтэнд усложнять для хранения двух токенов.. ну или что бы фронтенду приходилось в отдельный роут стучать для рефреша токена, а затем повторять исходный запрос..

я вот думаю, может промисами как-то можно. Типа с помощью Promise.all

можно конечно const query = util.promisify(connection.query); query('SELECT 1').then(results => { const promises = results.map(el => query("SELECT 2").then(r => el.price = r)); Promise.all(promises).then(()=>res.send(results)); })

как-то так

(писал на коленке могут быть тупые ошибки типа пропущенной скобки)

А посоветуйте как с в express и jsonwebtoken легко и правильно рефрешить токен? лучше не с отдельным роутом который по старому токену отдает новый. А с одной универсальной миддварей авторизации. Думаю нужна такая логика: - Если токен не устарел вернуть юзера - Если токен устарел, но пригоден для рефреша, то рефрешить вернуть юзера и новый токен - Если токен устарел полностью включая REFRESH_LIFE_TIME или не валиден, не существует.. и далее передать просто user равный null и сообщение что не удалось авторизовать... но не ошибку. Так вообще делают? я видел похожие примеры, но до конца что то их не догоняю... ну и не будет ли такой алгоритм проблемой с безопасностью?

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

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

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

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

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

как то его блеклистить?

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

это пока все же лишнее.. тем более приложение совсем не критичное в плане авторизации..

не оплата итп...

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

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

но рефрешить тоже можно ограниченный срок.. скажем токен валиден несколько часов, а рефрешить его можно скажем неделю... так ведь обычно делают? но надо видимо блеклистить после рефреша...

обычно хранят все валидные токены в БД вместе с профилем пользователя, и проверяют их. для этого кстати jwt не нужен

если токен заэкспайрился, рефрешишь, старый удаляешь из профиля, новый закидываешь туда и отдаешь юзеру

обычно хранят все валидные токены в БД вместе с профилем пользователя, и проверяют их. для этого кстати jwt не нужен

у нас профиль юзера не храниться в БД.. свои особенности..

ну вот тут я вижу что все валидные рефреш токены кладут в массив... его рекомендуют хранит в redis или типа того.. удалять оттуда.. это типа стандартного решения?

Есть ли логи у ноды ? Как можно узнать почему крашит сервер?

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

(если сделать "во-первых", то "во-вторых" произойдет автоматически)

а чем вариант с Promise all не понравился?

с промисами еще не пробовал

а как у тебя там вообще await работает интересно? await должен промис ждать оно заменяет callback, т.е. callback больше не нужен

т.е. вместо connection.query('SELECT', function(err, results) { ... })будет const results = await query('SELECT');

только query != connection.query сделай const util = require('util');наверху где все require и потом const query = util.promisify(connection.query)

и почитай плз что-нибудь про async-await и про промисы тоже. это basics, такими вещами стыдно должно быть людей напрягать. всё уже написано подробно, куча статей, видео, на любом языке - гугл в помощь

ну вот тут я вижу что все валидные рефреш токены кладут в массив... его рекомендуют хранит в redis или типа того.. удалять оттуда.. это типа стандартного решения?

стандартов в данном случае не существует

но слышал что люди рекомендуют не делать jwt если плохо в них шаришь. потому как легко накосячить ?

думаю можно и в редис хранить, какая разница

только не блэклист, а список валидных токенов естественно

только не блэклист, а список валидных токенов естественно

да это понятно. Главная проблема. Я не хочу фронтенд усложнять надобность стучать в отдельный роут для рефреш токена..

По логике фронтенда хочу так: Делаем запрос к бекенду с токеном, бекенд отдал или - юзера - юзера и новый токен - сообщение что не авторизован и все... это нужно и тк у меня не два вида страниц открытие и закрытые.. скорее такие типы страниц (на фронтенде): -закрытые не авторизованный вышвыривается - открытые не авторизованный остаеться. но важно знать авторизован или нет. - гостевые типа логина/регистрации. авторизованный вышвыривается Если на каждую ошибку авторизации я буду на фронте вызывать рефреш токен в axios interceptor и повтор запроса... то зачем мне это к примеру на открытых страницах... где авторизация не обязательна, но нужна знать есть ли все таки она.. все конечно можно сделать и увязать.. но писать какую то сложнотень нет совершенно времени.. и будут трудности в отладке..

Может что готовое есть?

В тоже время безопасность прямо уровня биллинга не нужна..

только не блэклист, а список валидных токенов естественно

В редисе как раз хранят блеклист непротухших рефрешей

В редисе как раз хранят блеклист непротухших рефрешей

Это все ясно. Вопрос в том как обойтись без отдельного роута для рефреш токен. И повторных запросов на фронтенде. Или убедите что это не возможно тогда буду делать по сложной схеме..

Это все ясно. Вопрос в том как обойтись без отдельного роута для рефреш токен. И повторных запросов на фронтенде. Или убедите что это не возможно тогда буду делать по сложной схеме..

Тут просто не выйдет, завтра схему вышлю если в личке напишите

В редисе как раз хранят блеклист непротухших рефрешей

блеклист это если бы ты там хранил протухшие а если непротухшие то по всем законам жанра это называется whitelist

Тут просто не выйдет, завтра схему вышлю если в личке напишите

Напишу... есть какие то свои наработки?

Что такое paranoid: true?

блеклист это если бы ты там хранил протухшие а если непротухшие то по всем законам жанра это называется whitelist

формально да. токены блеклистем, удаляя из вайтлиста..

Что такое paranoid: true?

по мойму прикол автора..

А как такая штука https://github.com/meanie/passport-refresh-strategy ?

по мойму прикол автора..

Не раз видел

Кому-то известны альтернативы QuokkaJs?

Напишу... есть какие то свои наработки?

Да, мы с товарищем всю схему наваяли

Да, мы с товарищем всю схему наваяли

здорово..

привет

кто то ещё не спит?

есть не большой вопрос

кто может помочь

?

Мне тут нужно не большую функцию сделать Класс с функцией, которая с интернета по ссылке может скачать файл и сохранить на компе но она должна быть асинхронна с использованием async и await

Мне тут нужно не большую функцию сделать Класс с функцией, которая с интернета по ссылке может скачать файл и сохранить на компе но она должна быть асинхронна с использованием async и await

а помочь то с чем.

?

Мне тут нужно не большую функцию сделать Класс с функцией, которая с интернета по ссылке может скачать файл и сохранить на компе но она должна быть асинхронна с использованием async и await

Вроде есть примитивные GET сразу в http модуль встроеные, есть ещё более продвинутый request в том же http. Или бери axios

Что такое paranoid: true?

Не удалять строки из БД, а устанавливать deletedAt

Привет. использую koa, koa-static, но в мой мидлвар после app.use(stat), мне все равно прилетают запросы на статику, как отфильтровать эти запросы?

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

Привет ребят

Подскажите, есть такая ситуация. нужно один скрипт запустить на Node 0.14, а другой на той же машине запустить под node 8. Как лучше это реализовать?

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

nvm вроде только переключает версии

В одном терминале запускаешь 0.14, в другом 8

он любую выкачивает

В одном терминале запускаешь 0.14, в другом 8

а как запустить под другой версией?

какой флаг поставить нужно

а как запустить под другой версией?

Доку почитать не?

ладно, еслит сложно, ща поищу