^

Погоди, что ты имеешь ввиду под "на голом железе"?

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

ну первый раз я это в докере поймал

Что происходит с сокетом после закрытия? Просто удаляется файл и все?

Это по барабану, попробуй воспроизвести на нормальном ядре

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

какое ядро ты считаешь нормальным?

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

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

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

как понять Blackbox?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Народ. А как в 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)

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

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

Народ. А как в 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) } Пробовал так, но процесс запустился но не убился. Никаких ошибок нет. Видимо какой-то другой механизм

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

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

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

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

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

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

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

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

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

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

Почему?

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

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

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

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

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