При чем тут модель. Я это все кладу в контроллер

не должно это там быть, это не его задача

Может я туплю, но совершенно не понимаю где это ещё можно сделать

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

Ну так я про то и пишу. Перечитай мое сообщение - 2 раза стукнуть модель, сервис смс, сервис емэил, задать таск. На все по строчке, плюс обработка ошибок

Если вы пишете о том что не надо в контроллере по http сдать запросы на сторонний сервис - то это блин пипец и так понятно

тогда как это связанно с тонкой моделью?

+ ты написал "сторонний сервис", это выглядело как сделать запрос

возможно просто не правильно поняли

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

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

Я имел в виду что долбится из контроллера конечно мало кто будет - это полная камасутра, а вот протупить с моделью любят все

Ребят, бэкенд для мобильного приложения как авторизироваться принято сейчас? JWT в хедере, или oauth2 токены?

Я чёт сижу и не могу понять зачем вообще jwt нужен

зависит от если тебе ничего про клиента в мобилке из токена не надо - то просто access_token

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

но я так понимаю не сделаешь же соль одну на всех?

А это значит что нужно будет лазить в кэш за солью

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

ты про ту, которой jwt подписывается?

ты про ту, которой jwt подписывается?

да

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

Если кто-то ухнает x509 он может что угодно подписать

и я буду думать что всё норм

ну, дружище, терять приватные ключи - это всегда пиздец :)

Я имею ввиду что если все тоекны одним и тем же шифровать - его ломануть можно перебором

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

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

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

И всё это лежит в jwt

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

А потом им подписать всё что угодно

Ну если я правильно понимаю

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

ты про сценарий, когда ты подобрал приватный ключ, нагенерил jwt, прописал себе iddqd и засылаешь его мне? но я могу соль делать динамическую, мне она только в бекенде нужна. могу обновлять её единожды для всех хоть раз в сутки для веба некоторые используют такую связку: 1. классическая сессия для пользователя 2. словарь сессия-токен 3. токен уходит в микросервисы

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

Так почему бы не брать оттуда то, что в пэйлоаде жвт, если ты всё равно вынужден куда-то обращаться

Вместо жвт соответственно

а зачем мне куда то обращаться? если это HMACSHA256 то мне для проверки подписи нужен секрет он у меня может динамически генериться раз в сутки по какому-то алгоритму. алгоритм на всем бекенде известен, куда-то ходить лишний раз не надо. ну сессия - это какое то состояние ;) а здесь отсутствие состояние. можно указать начало жизни токена, время окончания и массу полезных фишек.

Те типо ты для проверки используешь к примеру соль производную от времени

Ну тогда все логично

ну то есть я говорю что у меня токен живет сутки раз в сутки меняется секрет

Прост ща рефакторинг проект - там в хедере токен и отдельно юзер ид. И мне все не нравится

Я думал сделать оаус с рефреешем и просто токеном

Но походу жвт ниче так зайдёт

Ну и логика - по токену фетчится сессия с редиса и сравнивается ид там и в хедере

Я думал сделать оаус с рефреешем и просто токеном

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

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

А в безопастности велосипеды как то я не люблю

Потому что нифига крипту не знаю

вот тут очень обзорный доклад про jwt https://www.youtube.com/watch?v=67mezK3NzpU cмотреть лучше сразу на 1.5х скорости ;) юмор тоже приятный

Ща осталось понять только как рефрешить jwt

Ща осталось понять только как рефрешить jwt

так же, как в случае с обычным access_token + refresh_token

Так то вроде нету refresh jwt

А ну блин, логично же

Нужно просто отдельный endpoint который даст новый jwt

И новый рефреш

так jwt это просто формат записи. ты передаешь его как access_token (если мы про oauth2 говорим)

Дада, понял уже

Обычный короче oauth2 просто я в токене прямо инфу храню

йеп

Есть че для феникса готовое?

Походу придётся на коленке собирать на плаге как всегда

Есть че для феникса готовое?

твои любимые плаги? ;) plug jwt

у guardian может есть чего..

Я как понял - в новых сутках меняется соль, сервер говорит - ваш jwt говно, ты рефрешем подбираешь новый - ура

ERROR: S client not available

я сам всю неделю мучаюсь, писать лень, но нужно поменять всю авторизацию/аутентификацию/регистрацию :( команда умеет c# но меня он достал.. подумываю о диверсии

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

Короче 7 бед- один ответ "ваш токен говно"

А рефреш норм в бд хранить, или всетки редис? Хотя какой блин редис, токен может дольше жить чем сервак...

Короче используя jwt я вообще редис выкину

А рефреш норм в бд хранить, или всетки редис? Хотя какой блин редис, токен может дольше жить чем сервак...

ну у тебя же stateless, сессии нет. ну будет у клиента токен, а твой сервер сделает let it crash ну потом придет клиент с токеном, попробует отрефрешить, ему скажет - токен у тебя говно! он выкинет на страничку аутентификации. не страшно же? если страшно - то персисти где-то его, от таких казусов

Мне кажется бд оптимально для такого

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

А внутри феникса рефреш нигде не похранишь

Ну можно типо отдельный генсервер - но как то криво чтоли

А че ты гард не юзаешь

Там же все из коробки с этим jwt

Хз

Или ты прогениацию

?

Так то мне рефакторинг надо делать

Я делал Спайк проектик

Я ещё не смотрел как че

Там и заюзал все вроде работало

Тут такое дело, я в поисках работы В основном пишу на python'е+django, когда то давно для себя баловался erlang'ом Вдруг кому то нужен питонист, но и с радостью могу переквалифицироваться в елексирщика Вот мое резюме https://docs.google.com/document/d/1ytb9mIVnU-08mLyGw5ZgeqqyERtXVY7NZcH_27te_NA

На всякий случай, пример кода на erlang, это телеграм бот, писал достаточно давно https://github.com/radist101/raboter/blob/master/src/raboter.erl

не очень по теме, но не возбраняется

Хорошо тогда

На всякий случай, пример кода на erlang, это телеграм бот, писал достаточно давно https://github.com/radist101/raboter/blob/master/src/raboter.erl

а зачем там timer:sleep(3000) на 32 строчке?

в режиме long-polling спать не нужно, телега не отпустит твой запрос, пока таймаут не выйдет или данные тебе не отправит

На всякий случай, пример кода на erlang, это телеграм бот, писал достаточно давно https://github.com/radist101/raboter/blob/master/src/raboter.erl

"моб приложения" лучше целиком писать

а зачем там timer:sleep(3000) на 32 строчке?

эх, вспомнить бы зачем я такое написал

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

"моб приложения" лучше целиком писать

спасибо, поправил

спасибо, поправил

еще это, лучше сделать какой-то proof of skills отдельно

типа найди какую-то задачу для реализации на эрланге/эликсире