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

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

Blackbox + обычные сессии будет ок

Blackbox + обычные сессии будет ок

как понять Blackbox?

каких проблем у тебя нет на центосном (каком, кстати) ядре?

С очень частым открытием/закрытием сокетов. При чём на убунте у меня такое бывало, но я не докапывался почему именно, попробовал цент и всё взлетело

как понять Blackbox?

Сервис с простым апи, который имеет доступ к пользовательским данным. Остальные сервисы доступа не имеют

Вся авторизация и проверка сессий на стороне этого сервиса

Вся авторизация и проверка сессий на стороне этого сервиса

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

А как сервис работает - другие сервисы не знают и знать не должны

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

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

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

Клиент первым запросом делает public auth на блэкбоксе, получает sso сессию и токен, а дальше ходит с сессией и токеном на апи гейтвей или, если его нет, то на сервисы напрямую. Сервисы валидируют комбинацию session id и токена на блэкбоксе перед auth-only req

аутефикацию можно вынести на api gateway если она по JWT токену, так-то в токен можно права доступа добавить

каких проблем у тебя нет на центосном (каком, кстати) ядре?

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

аутефикацию можно вынести на api gateway если она по JWT токену, так-то в токен можно права доступа добавить

Тогда челу придется переполучать токен при обновлении прав, это плохо для UX

Клиент первым запросом делает public auth на блэкбоксе, получает sso сессию и токен, а дальше ходит с сессией и токеном на апи гейтвей или, если его нет, то на сервисы напрямую. Сервисы валидируют комбинацию session id и токена на блэкбоксе перед auth-only req

»Сервисы валидируют комбинацию session id и токена на блэкбоксе перед auth-only req имеется в виду, что сервис на каждый пользовательский запрос идет на auth сервис и там проверяет права, так?

»Сервисы валидируют комбинацию session id и токена на блэкбоксе перед auth-only req имеется в виду, что сервис на каждый пользовательский запрос идет на auth сервис и там проверяет права, так?

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

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

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

Да не за что

Тогда челу придется переполучать токен при обновлении прав, это плохо для UX

А в чем проблема? Api gateway возвращает код что нужно обновить токен и уже с новым токеном выполняется запрос

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

еще вот такой смежный вопрос — обычно это все через k8s делается, или просто docker достаточно?

еще вот такой смежный вопрос — обычно это все через k8s делается, или просто docker достаточно?

Зависит от того, что нужно. Если хватает допера - сиди на допере, не усложняй жизнь k8s

А в чем проблема? Api gateway возвращает код что нужно обновить токен и уже с новым токеном выполняется запрос

Ну - jwt by default имеет свой project-wide ключ, верно?

Зависит от того, что нужно. Если хватает допера - сиди на допере, не усложняй жизнь k8s

спасибо

Ну - jwt by default имеет свой project-wide ключ, верно?

Он нужен только на гейтвее

Он нужен только на гейтвее

не в этом суть любой мастер ключ — это то, что нужно хитро защищать. зачем, если можно сделать проще, и при этом не менее надёжно?

jwt эта та же информаци из сессии только она хранится на стороне клиента, на один сервис меньше получается

если у тебя не было api gateway, то вообще по барабану, всё равно +1 сервис

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

Народ. А как в go грохнуть запушенный процесс? cmd := exec.Command("/usr/local/bin/gedit", "/home/pi/test.txt") err := cmd.Run() if err != nil { panic(err) } err = cmd.Process.Kill() if err != nil { panic(err) } Пробовал так, но процесс запустился но не убился. Никаких ошибок нет. Видимо какой-то другой механизм

Народ. А как в go грохнуть запушенный процесс? cmd := exec.Command("/usr/local/bin/gedit", "/home/pi/test.txt") err := cmd.Run() if err != nil { panic(err) } err = cmd.Process.Kill() if err != nil { panic(err) } Пробовал так, но процесс запустился но не убился. Никаких ошибок нет. Видимо какой-то другой механизм

> Никаких ошибок нет так ты их не проверяешь

> Никаких ошибок нет так ты их не проверяешь

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

но можно повторит, да

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

Народ. А как в go грохнуть запушенный процесс? cmd := exec.Command("/usr/local/bin/gedit", "/home/pi/test.txt") err := cmd.Run() if err != nil { panic(err) } err = cmd.Process.Kill() if err != nil { panic(err) } Пробовал так, но процесс запустился но не убился. Никаких ошибок нет. Видимо какой-то другой механизм

Нужно после запуска id процесса получать и убивать процесс по id p := exec.Command() p.Start() pid := p.Process.Pid process, _ := os.FindProcess(pid) process.Signal(syscall.SIGTERM)

Нужно после запуска id процесса получать и убивать процесс по id p := exec.Command() p.Start() pid := p.Process.Pid process, _ := os.FindProcess(pid) process.Signal(syscall.SIGTERM)

Он так и делает

Он так и делает

Я выше исправил коммент, добавил код

Ток проверки ошибок не забыть :)

Я выше исправил коммент, добавил код

Kill ровно это и делает

Народ. А как в go грохнуть запушенный процесс? cmd := exec.Command("/usr/local/bin/gedit", "/home/pi/test.txt") err := cmd.Run() if err != nil { panic(err) } err = cmd.Process.Kill() if err != nil { panic(err) } Пробовал так, но процесс запустился но не убился. Никаких ошибок нет. Видимо какой-то другой механизм

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

kill -9 надо

Как он там называется...

https://ru.m.wikipedia.org/wiki/Сигнал_(Unix) там табличка классификаций

Народ. А как в go грохнуть запушенный процесс? cmd := exec.Command("/usr/local/bin/gedit", "/home/pi/test.txt") err := cmd.Run() if err != nil { panic(err) } err = cmd.Process.Kill() if err != nil { panic(err) } Пробовал так, но процесс запустился но не убился. Никаких ошибок нет. Видимо какой-то другой механизм

Вместо cmd.Run() cmd.Start(), тогда не детачится

не в этом суть любой мастер ключ — это то, что нужно хитро защищать. зачем, если можно сделать проще, и при этом не менее надёжно?

Я вот о чем подумал, а как происходит взаимодействие между двумя сервисами, когда один идёт за проверкой прав пользователя на сервис авторизации? Он же спалит данные пользователя

Я вот о чем подумал, а как происходит взаимодействие между двумя сервисами, когда один идёт за проверкой прав пользователя на сервис авторизации? Он же спалит данные пользователя

кто он спалит и почему?

кто он спалит и почему?

Например. Я иду на сервис авторизации, получаю токен и сессию. Потом с этим иду на второй сервис, который не имеет доступа к данным пользователя и вынужден идти проверять данные, которые я прислал, на сервис авторизации. Так? Тогда вот этот самый последний поход сервиса 2, к сервису авторизации как осуществляется?

Например. Я иду на сервис авторизации, получаю токен и сессию. Потом с этим иду на второй сервис, который не имеет доступа к данным пользователя и вынужден идти проверять данные, которые я прислал, на сервис авторизации. Так? Тогда вот этот самый последний поход сервиса 2, к сервису авторизации как осуществляется?

Чтоб было безопасно передать данные пользователя для проверки

Например. Я иду на сервис авторизации, получаю токен и сессию. Потом с этим иду на второй сервис, который не имеет доступа к данным пользователя и вынужден идти проверять данные, которые я прислал, на сервис авторизации. Так? Тогда вот этот самый последний поход сервиса 2, к сервису авторизации как осуществляется?

У тебя идет передача запроса на endpoint, а дальше сервисы взаимодействуют друг с другом. Т.е. для примера ты прислал запрос на получение постов пользователя на endpoint в составе social сервиса, в составе запроса есть токен авторизации. Т.е. до того как social сервис тебе отдаст данные, он должен отправить запрос на user сервис с полученным токеном и получить от него ответ о валидности

Например. Я иду на сервис авторизации, получаю токен и сессию. Потом с этим иду на второй сервис, который не имеет доступа к данным пользователя и вынужден идти проверять данные, которые я прислал, на сервис авторизации. Так? Тогда вот этот самый последний поход сервиса 2, к сервису авторизации как осуществляется?

Не понял вопроса, но лучше хотя бы по https

У тебя идет передача запроса на endpoint, а дальше сервисы взаимодействуют друг с другом. Т.е. для примера ты прислал запрос на получение постов пользователя на endpoint в составе social сервиса, в составе запроса есть токен авторизации. Т.е. до того как social сервис тебе отдаст данные, он должен отправить запрос на user сервис с полученным токеном и получить от него ответ о валидности

Хорошо, это понятно. Я, видимо, неправильно вопрос написал. По какому протоколу общаются между собой сервисы?

Хорошо, это понятно. Я, видимо, неправильно вопрос написал. По какому протоколу общаются между собой сервисы?

А тут как тебе удобно. У меня в реализациях по amqp обычно, через кролика или кафку. Можно через http и тут тоже не будет криминала, т.к. запросы host 2 host, между двумя твоими серверами

Btw, вы не путаете авторизацию с аутентификацией?

Просто ходить на внешний ресурс за авторизацией это странно

А тут как тебе удобно. У меня в реализациях по amqp обычно, через кролика или кафку. Можно через http и тут тоже не будет криминала, т.к. запросы host 2 host, между двумя твоими серверами

Host 2 host тогда должны быть во внутренней сети, да?

Просто ходить на внешний ресурс за авторизацией это странно

Почему?

Почему?

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

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

Да, при таком раскладе норм

Host 2 host тогда должны быть во внутренней сети, да?

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

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

А для работы с каким нибудь гуглом, вам должно хватить аутентификации, там тоже ничего не сливается Соответсвенно https

Btw, вы не путаете авторизацию с аутентификацией?

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

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

Ну я не только вам; ну и в данном случае он важна

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

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

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

Так может быть и отдельный виртуальный сервер. Что тебя смущает, пока не понимаю?

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

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

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

ERROR: S client not available

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

спасибо!

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

Там ничего сложного, если что велком в личку)

TWIMC: вчерашняя проблема с listen оказалась очень странной: нельзя слишком часто открывать-закрывать unix сокеты. от этого что-то где-то ломается, и listen сокет закрывается надо бы багрепорт написать, но непонятно, куда

ужас какой. Возникает вопрос, слишком часто - это сколько в цифрах?

100 раз в секунду, примерно

Оно плавает слегка

Забыл как в спецификаторах формата для семейства функции fmt указать чтобы числа от 1 до 9 печатались с лидирующим нулём. Подскажите плиз

С одним?

да

Нзна

%5.5d - это про другое

fmt.Sprintf("%02d", value)

точняк, сапсибо

Извините заранее если вопрос уже обсуждался. Допустим я сделал несколько функций и пускаю их только рефлексом. Го разве не выкинет эти функции так как они нигде не используются?

Ребята, я тут AMQP сервер запилил, и очень был бы рад замечаниям, предложениям, конечно же лайкам и особенно критике, можно в личку. Это мой первый большой проект на Go, забрасывать не хочу и буду продолжать над ним работать https://github.com/valinurovam/garagemq

А кто-нибудь делал метрики для prometheus в приложении? Все пишут полный список метрик со всеми параметрами а потом их используют? Или есть какие-то более удобные решения?

А кто-нибудь делал метрики для prometheus в приложении? Все пишут полный список метрик со всеми параметрами а потом их используют? Или есть какие-то более удобные решения?

просто посмотри пример metrics middleware в gramework

Да, вроде тут поинтереснее чем то, что я находил...

:)

Ребята, я тут AMQP сервер запилил, и очень был бы рад замечаниям, предложениям, конечно же лайкам и особенно критике, можно в личку. Это мой первый большой проект на Go, забрасывать не хочу и буду продолжать над ним работать https://github.com/valinurovam/garagemq

Это аналог rabbitmq?

Это аналог rabbitmq?

Да, постарался поддержать некоторые его отклонения от официального протокола и конфирмы

Ребята, я тут AMQP сервер запилил, и очень был бы рад замечаниям, предложениям, конечно же лайкам и особенно критике, можно в личку. Это мой первый большой проект на Go, забрасывать не хочу и буду продолжать над ним работать https://github.com/valinurovam/garagemq

Доки, экземплы, бенчи

цель какая была? написать на го? профиты какие?

Доки, экземплы, бенчи

По докам не совсем представляю что писать, запустил сервер и используешь как rabbit с любым AMQP-клиентом, то же самое с примерами... Бенчи да, но могу приложить только бенчи которые тулзой от реббита

По докам не совсем представляю что писать, запустил сервер и используешь как rabbit с любым AMQP-клиентом, то же самое с примерами... Бенчи да, но могу приложить только бенчи которые тулзой от реббита

Лол. Доки - посмотрите примеры от того же кролика или там ActiveMQ. Если хотите чтобы продуктом кто-то пользовался, возьмите за образец успешные OSS проекты

цель какая была? написать на го? профиты какие?

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

Простите, но не верю. Это про скорость

Или вы ampq не реализовали, либо кролик работает в режиме когда он сообщения персистит иди там гарантирует доставку, а ваше решение - как повезёт

Ну, тестил на локальной машине. Да и мои тесты да, так себе, очень синтетические

Условия одинаковые, режим сообщений в памяти) AMQP реализован. На счёт как повезёт - поэтому и вбрасываю в сообщество, может кто-то потестит, что-то подскажет. Доку наполню инфой как запускать и т д, хотя там достаточно make run

и подумайте про конфигурацию

хотя бы в каком-то виде