ходит в мою апишку?”. Ибо все внутренние API были доступны без токенов. Сделал пакет для back-to-back авторизации через JWT токены.
Что думаете, нормально задизайнен пакет?
https://gitlab.com/denuly54/awesome_golang/-/tree/master/pkg/b2bauth
Простите, в случае, когда сервер ходит к другому серверу, в чем отличие от классической клиент-серверной архитектуры?
Да толком не в чём. Но когда я живу внутри куба большой компании и разрабатываю сервис “А”, я не хочу чтоб Петя из другого отдела без разрешения ходил ко мне из своего сервиса. Такие рандомные походы - ад для архитектуры, ибо не все сервисы предназначены для вызова за пределами моего домена.
а чем обычный apikey не подошёл?
А он был в первой версии. Со стороны инфраструктуры поступила просьба: “а можно такой apikey, чтоб понятно было кто и к кому ходит”. По сути это и есть apikey - только с доп инфой и секретом
Ну потребитель хранит свой токен к моему сервису в vault
так через авторизацию в волте понятно кто ходит в вашу апи
А, понял. Бесконечно согласен с тобой. Сам сначала (в версии 0 при решении проблемы) разруливал через ServiceMash. Но вот минусы: 1) сегодня Истио, завтра Херистио 2) всё равно ушлый Петя может админов попросить и ходить в мой сервис
1. ну, нет. сегодня истио, завтра линкерд не так уж просто реализовать. 2. тут да, организационный момент.
Да, тема. Хотелось иметь возможность прям из токена инфу прочесть
Чот даже расстроился. Ничего для чистых кубов не гуглится готового.
+. Так это же чуть-ли не филлософская тема. Хочешь систему без зависимостей - не тащи зависимостей. В решении с JWT от инфры вообще нечего не требуется, так как мы основываемся тупо на HTTP
так проблема то в чем? это вроде как пишется довольно быстро...
Так я и сделал и просил критики 🙂
Обсуждают сегодня