Логика + разметка в одним месте

На вуе так большинство пишет)

И это неверно

На вуе так большинство пишет)

?

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

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

Ты слишком токсичным стал

если сильно разносить логику и разметку вообще срака будет...потом шастай по папкам вложенностью в 5 уровней

От реактовцев заразился

Ты слишком токсичным стал

Бывает

всем привет!

если сильно разносить логику и разметку вообще срака будет...потом шастай по папкам вложенностью в 5 уровней

Для этого и придумали некие паттерны

А давайте опять поговорим за jwt авторизацию с бекендом на node

Вот какой смысл иметь все же 2 токена и обновлять refresh_token по отдельному url

Для этого и придумали некие паттерны

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

ведь получаеться что refresh_token можно украсть и по нему сколько угодно получать access_token а url по которому рефрешить также не проблема подсмотреть.. так толку?

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

Там гдет ссылка была прикольная. С мобилы не найду

почему это так рекомендуют..

jwt вообще не рекомендуют для авторизации

jwt вообще не рекомендуют для авторизации

я знаю про сессии итп.

ну а коли уж используеться jwt тк так решили итп..

если сильно разносить логику и разметку вообще срака будет...потом шастай по папкам вложенностью в 5 уровней

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

ведь получаеться что refresh_token можно украсть и по нему сколько угодно получать access_token а url по которому рефрешить также не проблема подсмотреть.. так толку?

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

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

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

Просто суть в том что я весь этот код с рефреш токеном и /refresh_token роутом накатал он работает.. но я вот думаю о мотивации.. зачем все это... коли берешь это refresh_token и также пользуешь все как одним токеном ..

народ, подскажите по переменным окружения во vue cli 3.. я создал .env рядом с package.json потом запускаю дев сервер и в какомнибудь компоненте вывожу в консоль console.log(process.env.VUE_APP_MY_VAR), а оно undefined что я делаю не так?

народ, подскажите по переменным окружения во vue cli 3.. я создал .env рядом с package.json потом запускаю дев сервер и в какомнибудь компоненте вывожу в консоль console.log(process.env.VUE_APP_MY_VAR), а оно undefined что я делаю не так?

наверное нужен пакет dotenv и его инициализировать где нужно

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

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

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

приведи пример где описано? ты имеешь ввиду соль в token добавить итп? все это применимо ведь и к одному token?

наверное нужен пакет dotenv и его инициализировать где нужно

в доке про этот пакет ни слова

главное в авторизациях не сходить с ума, реализоывал процедуру по мануалу и хватит на этом. Никому не нужны ваши никчемные сайтики чтобы их мучаться ломать. А если уж и решат ломать то сломают и хер вас что спасет. С авторизацийе есть мысл париться только если на сайте действительно есть данные конфиденциеальные такие как транзакции кошельки номера карт. Но тогда это выносится в большой таск по защите сайта и страдают отдельно уже. Я в свое время cognito токен поднял не особо мучаясь и этого хватило

в доке про этот пакет ни слова

ну не знаю я пользовался и .env читался..

приведи пример где описано? ты имеешь ввиду соль в token добавить итп? все это применимо ведь и к одному token?

https://www.youtube.com/playlist?list=PLvTBThJr861y60LQrUGpJNPu3Nt2EeQsP Нет, я не про соль, я про то что при сохранении рефреша для юзера можно рядом класть мету, которая поможет разрулить угон

главное в авторизациях не сходить с ума, реализоывал процедуру по мануалу и хватит на этом. Никому не нужны ваши никчемные сайтики чтобы их мучаться ломать. А если уж и решат ломать то сломают и хер вас что спасет. С авторизацийе есть мысл париться только если на сайте действительно есть данные конфиденциеальные такие как транзакции кошельки номера карт. Но тогда это выносится в большой таск по защите сайта и страдают отдельно уже. Я в свое время cognito токен поднял не особо мучаясь и этого хватило

я тоже так думаю... потому и не понимаю зачем вся эта хрень с refresh. Ну я делал типа оч. примерно как тут https://codeforgeek.com/2018/03/refresh-token-jwt-nodejs-authentication/

я тоже так думаю... потому и не понимаю зачем вся эта хрень с refresh. Ну я делал типа оч. примерно как тут https://codeforgeek.com/2018/03/refresh-token-jwt-nodejs-authentication/

ну так и сделай...потом переделаешь если попросят

https://www.youtube.com/playlist?list=PLvTBThJr861y60LQrUGpJNPu3Nt2EeQsP Нет, я не про соль, я про то что при сохранении рефреша для юзера можно рядом класть мету, которая поможет разрулить угон

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

ну так и сделай...потом переделаешь если попросят

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

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

Ты мыслишь связкой юзер + токен, а я юзер+токен+мета

Ты мыслишь связкой юзер + токен, а я юзер+токен+мета

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

ну типа в сам токен зашифровать еще какую то строку и записать в БД..

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

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

один токен нельзя хотя бы потому что работа с рефрешем дорогая и делать её так часто приведет к увеличению latency. Ну а остальные причины - теория jwt. нет таких статей, мета это данные которыми ты можешь разрулить угон, они не лежат в токене, они только на бэке. А что за данные это сильно ситуативно, зависит от проекта и твоего скилла - какой способ ты примешь за надежный, поэтому статей таких ты не найдешь

один токен нельзя хотя бы потому что работа с рефрешем дорогая и делать её так часто приведет к увеличению latency. Ну а остальные причины - теория jwt. нет таких статей, мета это данные которыми ты можешь разрулить угон, они не лежат в токене, они только на бэке. А что за данные это сильно ситуативно, зависит от проекта и твоего скилла - какой способ ты примешь за надежный, поэтому статей таких ты не найдешь

если они только на беке... то как их проверять при запросе..

что с чем сравнивать

если они только на беке... то как их проверять при запросе..

Ну это мега странный вопрос

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

"один токен нельзя хотя бы потому что работа с рефрешем дорогая и делать её так часто приведет к увеличению latency." те работа с рефреш его валидация и заново создание итп должна быть дороже чем с просто token ?

"один токен нельзя хотя бы потому что работа с рефрешем дорогая и делать её так часто приведет к увеличению latency." те работа с рефреш его валидация и заново создание итп должна быть дороже чем с просто token ?

ну конечно, проверка access это просто верификация токена

https://codeforgeek.com/2018/03/refresh-token-jwt-nodejs-authentication/ мне пока интересно норм ли по примерно такому мануалу.. конечно читал не только его.. а разные примеры итп..

ну конечно, проверка access это просто верификация токена

ну да верификация..

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

вот думаю можно ли как то упростить..

Access должен жить не дольше 5 минут, по твоему если из-за каждого юзера лезть в бд каждый 5 минут это норм? Тем более что это дорого.

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

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

а главный минус в чем.. конечно буду еще рефакторить

Access должен жить не дольше 5 минут, по твоему если из-за каждого юзера лезть в бд каждый 5 минут это норм? Тем более что это дорого.

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

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

максимум 15 минут

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

Если сходу 1. везде коллбеки 2. странное формирование expires, а не через конфиг 3. неправильное использование http кодов 4. Громоздко и не очень читабельно

Если сходу 1. везде коллбеки 2. странное формирование expires, а не через конфиг 3. неправильное использование http кодов 4. Громоздко и не очень читабельно

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

каллбеки заменить на try catch await

громоздко понятное дело..

по http 401, а как предлагаешь 403?

А стоит ли форсить try catch вместо callback прямо везде везде? к примеру внутри axios перехватчика нигде не видел try catch в примерах..

ERROR: S client not available

в аксиос перехватчика чего? Ошибки? Есть же

в аксиос перехватчика чего? Ошибки? Есть же

подправил свой пост..

принято)

ну он вроде как и не нужен там

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

ну это довольно странно

нода же тоже на коллбеках частенько

часто да.. но понятно что местами вместо callback try catch + await лучше каллбека.. особенно если за этим запросом еще один потом еще... и все должно идти последовательно одно после выполнения другого. но вроде это не те случаи что в моем приведенном коде..

кто-то испоьзовал Reusable Transitions?

их в main.js кидать?

классная тема, как я раньше не видел

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

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

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

чтоб UX flow исследовать)

в nuxt.js используя ssr как получить доступ к куки если компонент рендерится на сервере? т.е. изначально понятно что нужно куки парсер подключить к ноде, а дальше

в nuxt.js используя ssr как получить доступ к куки если компонент рендерится на сервере? т.е. изначально понятно что нужно куки парсер подключить к ноде, а дальше

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

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

а как иначе?

вариантов 0

как без куки?))

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

дальше в стор

и что мне это должно сказать?

подключаешь плагин, тянешь куки, хуяришь в стор

какой стор, тебе надо на сервере отрендерить\

на плагин вешаешь ssr: false

подключаешь плагин, тянешь куки, хуяришь в стор

тянешь куки? ты же сказал "зачем тебе куки"

тянешь куки? ты же сказал "зачем тебе куки"

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

точнее вопрос, используя ssr

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

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