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

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

@Atassis

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

что написал, я в 5 раз спрашиваю в чем проблема

что написал, я в 5 раз спрашиваю в чем проблема

так еще раз..

что написал, я в 5 раз спрашиваю в чем проблема

ты не можешь прочитать сообщения выше?

ты не можешь прочитать сообщения выше?

нет не могу, ты там все засрал

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

нахуй я тебе это все объясняю?

надо помошь - давай уточняющий вопрос. не надо, ну так не надо пздц

нахуй я тебе это все объясняю?

тоже интересно

нахуй я тебе это все объясняю?

так никто вам не поможет

так никто вам не поможет

лооооол

я так понял туту все только последние сообщения читают

роуты подключают модель

как передать в модель и роуты connection вот этот

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

или тебе нужны разные коннекшены?

зачем?

или тебе нужны разные коннекшены?

нет один. но мне нужно четко понимать что он подключен

он тебе напишет в консоль при запуске сервера

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

а в модели просто const mongoose = require("mongoose") ?

он тебе напишет в консоль при запуске сервера

ну пишет

нет. так тебе точнео дока нуна или туториал

нет. так тебе точнео дока нуна или туториал

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

mongoose.createConnection(' путаю с mogoose.Connect ?

да я понимаю разницу.

ConfigModel имортируй

Всем привет! ? Возможно подскажете где могу почитать про стратегию работы с сессиями если даны следующие условия: - сервер для rest api; - авторизация через jwt; - postgres (не принципиально) + redis (если нужно). В первую очередь интересует как лучше хранить данные пользователей, сессионные данные и рефреш jwt по ttl. Уже много гуглил и пока только запутал себя )

зачем тебе сесси, если у тебя jwt

при jwt не нужны сессии и кукисы и вот это все

зачем тебе сесси, если у тебя jwt

та вот думаю дать возможность пользователям делать логаут

вот так норм работает

та вот думаю дать возможность пользователям делать логаут

логаут с jwt тоже работает

Ну теперь то норм что написал?

две стратегии. Если у тебя один долгоживущий токен, то отдельная коллекция/таблица в которой делаешь блеклист токенов

вторая — если у тебя рефреш токены, то там проще

ConfigModel имортируй

ну это само собой и изначально так было

две стратегии. Если у тебя один долгоживущий токен, то отдельная коллекция/таблица в которой делаешь блеклист токенов

можно про эту подробнее..

https://github.com/nesso99/jwt-blacklist а если такую штуку для блеклиста токенов заюзать?

вторая — если у тебя рефреш токены, то там проще

думал сделать через рефреш токены с короткими TTL (10-20 мин)

спасибо за наводку, этот пример ещё не видел ?

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

при следующем обращении когда сдохнет его текущий токен конечно же

думал сделать через рефреш токены с короткими TTL (10-20 мин)

и я так думал... что бы они все время менялись. Но это был для фронтенда один token, а не 2

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

видимо просто token можно инвалидатить..

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

не именно как инвалидатить.. а все вместе архитектура..

это прям тема для статьи на хабре с картинкой из кучой стрелок )

Например такая схема: 1) Дернули роут реги или авторизации. Отсылаем фронтенду token и user. token генериться не на очень долго 2) Дернули роут типа /check_auth либо какой то роут типа /user_profile проверился token отдали user. делать это может глобальная для приложения миддваря. Если token expired то генерим другой, а текущий блеклистим. отдаем и token и user 3) Дернули /logout токен блеклистим..

это прям тема для статьи на хабре с картинкой из кучой стрелок )

ну а как я написал если без кучи стрелок?

сойдет?

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

что хранить, где хранить, как часто рефрешить, на что обратить внимание

или я параноик и игра не стоит свеч?!

что хранить, где хранить, как часто рефрешить, на что обратить внимание

ну тут читать маны.. .. и прочее примеры есть..

или я параноик и игра не стоит свеч?!

я считаю не стоит

смотря сколько критичное приложение... рано или поздно при моем подходе все token сдохнут..

что хранить, где хранить, как часто рефрешить, на что обратить внимание

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

есть такая либа - resources.js . кто-то юзал? Как сделать сортировку на массиве ресурсов?

https://github.com/codeforgeek/node-refresh-token/blob/master/app.js вот пример с двумя токенами.. Как Вам просто? секурно?

придеться ведь еще и фронт учить с двумя токенами работать..

https://github.com/codeforgeek/node-refresh-token/blob/master/app.js вот пример с двумя токенами.. Как Вам просто? секурно?

сенкс! заценю ?

придеться ведь еще и фронт учить с двумя токенами работать..

это уже проблема фронта ?

сенкс! заценю ?

это не я делал если что))

это уже проблема фронта ?

в моем случае я и фронт пишу. кроме непосредственно верстки.

так что моя.

ничего, вдруг это то чего я уже несколько дней ищу )

так что моя.

моя тоже )))

это уже проблема фронта ?

кстати, фронт в вопросе авторизации сложнее чем бек, по моим наблюдениям. по крайней мере спа.

кстати, фронт в вопросе авторизации сложнее чем бек, по моим наблюдениям. по крайней мере спа.

ну, с фронтом несколько больше опыта, поетому там как-раз проблем нет )

Всем аллоха! Подскажите, пожалуйста, в какой директории принято располагать свою нодовский сервак? Не в хомяке же?

ну, с фронтом несколько больше опыта, поетому там как-раз проблем нет )

странно. я сам фронтендер, но с беком справился гораздо быстрее, чем с фронтом, с этими сторами, интерсепторами, редиректами, guards и вообще полным отсутсвием лучших практик

есть же наверное бес практики?

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

Всем аллоха! Подскажите, пожалуйста, в какой директории принято располагать свою нодовский сервак? Не в хомяке же?

да по сути без разницы, главное следить за правами доступа

и не запускать ноду от судо)))

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

запустить от судо

1000 зависимостей

от 1500 человек

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

по jwt?

если не трудно то можн оссылку на лучшие практики по авторизации с вью

моя тоже )))

ну вот значит лучше решение с одним токеном..

какая связь между авторизацией и фронтовым фреймворком?

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

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

в котором как бэ нет слоя для работы с апи

да по сути без разницы, главное следить за правами доступа

мерси

какая связь между авторизацией и фронтовым фреймворком?

понятно все

по jwt?

да и по nuxt полно всего... ну там ясен принцеп axios плагин или модуль перехватчики для токенов. миддваря проверяет авторизацию дергая бек..

работа с токенами на фронте это задача не фреймворка, а библиотеки для работы с api

например axios

там работа с токенами реализуется в 10 строчек

например axios

ну да по сути axios и миддваря check-token

и потом можно использовать хоть с вью, хоть с реактом