rand_cache_plugin_next({CacheBits, CacheSize, <<>>}) -> Классика

Напомни завтра доберусь до компа, ввложу гист

"Выучил" уже синтаксис?)

Ну такое. В доку конечно надо смотреть часто... все таки другая школа. Перестроится очень сложно. Но безумно интересно. Целый новый мир...

@zloyuser Ты вчера обмолвился о том, что надо разделять пользователя и аккаунт. Что есть что и как их лучше делить на твой взгляд?

Это Domain Specific вопрос. Надо смотреть в каждом конкретном случае. Если приводить некие общие правила то User это только login, pass и правила авторизации. Аккаунт знает только идентификатор пользователя (и то не всегда это нужно) и содержит уже необходимые бизнес правила.

Это Domain Specific вопрос. Надо смотреть в каждом конкретном случае. Если приводить некие общие правила то User это только login, pass и правила авторизации. Аккаунт знает только идентификатор пользователя (и то не всегда это нужно) и содержит уже необходимые бизнес правила.

Ну вот есть у меня статические "Фичи", которые объединяются в динамически создаваемые "Роли" (1 роль - много фич). Список всех фич - есть доступный пользователю функционал. С одной стороны - это аккаунт, так как содержит что-то помимо логина и пароля. С другой стороны - эта инфа должна попасть в токен, чтобы на основе неё как-то строить интерфейс. Так же, допустим, есть флаг IsLocked у пользователя. Это к нему напрямую должно относиться или к аккаунту? И тут тоже двоякая фигня. Потому что при блокировке пользователя - надо ревоукнуть все его токены, чтобы запретить ему доступ моментально.

То что ты описал это как раз пользователь в моем понимании. Аутентификация + Авторизация. А аккаунт это скажем биллинговая информация.

Ну и опять же - блокировка юзера - это вызов API, который предоставляет не сервис аутентификации (он вообще никакой API не отдаёт кроме того, что необходим для работы OIDC). То бишь это вызывается API Endpoint в другом процессе.

То что ты описал это как раз пользователь в моем понимании. Аутентификация + Авторизация. А аккаунт это скажем биллинговая информация.

Ок, но тут есть проблема) Допустим, юзер мне не заплатил и я хочу его заблочить и отозвать все выданные ему токены.

А юзер, со всеми его токенами живёт на сервисе аутентификации. У которого публичный API только на интероп с внешним миром.

Ну вот аккаунт знает про баланс, следит за его списанием и при окончанием средст идет в User API и блочит пользователя.

Ок, но тут есть проблема) Допустим, юзер мне не заплатил и я хочу его заблочить и отозвать все выданные ему токены.

модуль пэйментов кидает сообщение что "этот чел не заплатил", которое превращается в команду для сервера авторизации о том что "заблочить его!"

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

Но суть не меняется.

модуль пэйментов кидает сообщение что "этот чел не заплатил", которое превращается в команду для сервера авторизации о том что "заблочить его!"

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

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

почему оно за пределами его зоны ответстветнности?

почему оно за пределами его зоны ответстветнности?

Потому что всё что он должен делать - это давать API, который описан в спеках OAuth 2.0 и OpenID Connect, и больше ничего.

Потому что всё что он должен делать - это давать API, который описан в спеках OAuth 2.0 и OpenID Connect, и больше ничего.

откуда родилось такое ограничение?

Он защищает другие сервисы. Но сам по себе является Entry-Point'ом.

Незащищённым.

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

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

Ну вот я к этому пришёл

Он защищает другие сервисы. Но сам по себе является Entry-Point'ом.

давай не будем путать микросервисы и просто сервисы

давай не будем путать микросервисы и просто сервисы

Ок, это всё микросервисы)

Отдельные приложения, в отдельных процессах

в том то и прикол что нет)

Тут два сервиса Credentials и User делящих общие данные.

твой oauth сервер может быть частью микросервиса работающего с кредами юзеров

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

Их можно реализовать как в одном приложении так и в нескольких, но данные придется шарить

да и вообще - авторизация это инфраструктура

как и поиск

и можно вообще не рассматривать это как микросервис.... а скорее просто как некие штуки которые обслуживают твои микросервисы.

твой oauth сервер может быть частью микросервиса работающего с кредами юзеров

Ну я хочу чтобы API работы с кредами юзеров было защищено. А защищает его oidc микросервис. То есть если он начинает предоставлять такой API, то он получается сам валидирует выданные им самим же токены. Что по мне - бред)

и можно вообще не рассматривать это как микросервис.... а скорее просто как некие штуки которые обслуживают твои микросервисы.

Ну вот да. Только операции бизнес-логики на неё влияют.

Ну я хочу чтобы API работы с кредами юзеров было защищено. А защищает его oidc микросервис. То есть если он начинает предоставлять такой API, то он получается сам валидирует выданные им самим же токены. Что по мне - бред)

расскажи про поиск в контексте микросервисов - ты будешь делать отдельный микросервис ответственный за поиск или эта инфраструктура будет "размазана" по нескольким микросервисам?

Ну тобишь бизнес-ивент "закончились деньги на счету" => инфраструктурный ивент "заблочить юзера и отозвать все токены"

Ну тобишь бизнес-ивент "закончились деньги на счету" => инфраструктурный ивент "заблочить юзера и отозвать все токены"

да, так норм

Ну то бишь это 3 микросервиса вырисовывается. Первый - oidc, второй - внутренний, который менеджит юзеров полностью (находится в защищённом контуре и не торчит наружу от слова совсем) третий - публичный api, для менеджмента юзеров, защищённый токенами.

Ну то бишь это 3 микросервиса вырисовывается. Первый - oidc, второй - внутренний, который менеджит юзеров полностью (находится в защищённом контуре и не торчит наружу от слова совсем) третий - публичный api, для менеджмента юзеров, защищённый токенами.

то есть у тебя есть 2 микросервиса которые делят данные между собой?

то есть у тебя есть 2 микросервиса которые делят данные между собой?

Ну один предоставляет, два других потребляют.

Третий то вообще Gateway по сути.

Ну один предоставляет, два других потребляют.

еще раз - у тебя есть 2 сервиса, они работают с одними и теми же данными?

Гайс, как быть с DDD и вспомогательными, не бизнесс сервисами, например логированием. Вопрос сугубо технический (дайте код, или прям как вы решаете эту проблему) Например, у меня есть бизнесс модель Restaurant, Dish, Ingredient. Я создаю конкретный ресторан, с его конфигурацией, а потом прошу его приготовить конкретное блюдо. Где тут кошерно всунуть логгер. $restaurant = new Restaurant(array $dishes, array $ingredients); $restaurant->cook(Dish $dish);

Подскажите, это патерн какой-то?

Гайс, как быть с DDD и вспомогательными, не бизнесс сервисами, например логированием. Вопрос сугубо технический (дайте код, или прям как вы решаете эту проблему) Например, у меня есть бизнесс модель Restaurant, Dish, Ingredient. Я создаю конкретный ресторан, с его конфигурацией, а потом прошу его приготовить конкретное блюдо. Где тут кошерно всунуть логгер. $restaurant = new Restaurant(array $dishes, array $ingredients); $restaurant->cook(Dish $dish);

AOP?

Это пиздец

Подскажите, это патерн какой-то?

builder pattern

Дефолтная конфигурация Spring Security из гайда

Гайс, как быть с DDD и вспомогательными, не бизнесс сервисами, например логированием. Вопрос сугубо технический (дайте код, или прям как вы решаете эту проблему) Например, у меня есть бизнесс модель Restaurant, Dish, Ingredient. Я создаю конкретный ресторан, с его конфигурацией, а потом прошу его приготовить конкретное блюдо. Где тут кошерно всунуть логгер. $restaurant = new Restaurant(array $dishes, array $ingredients); $restaurant->cook(Dish $dish);

а как это так что ты готовое блюдо передаешь на готовку?)

еще раз - у тебя есть 2 сервиса, они работают с одними и теми же данными?

Не. 3 микросервиса. 1) Oidc сервер. Имеет 1 локальную базку с выданными токенами и своими внутренними настройками (клиенты, клэймсы, скоупы - вот это всё). При аутентификации юзера он ходит к микросервису юзеров и запрашивает у него инфу. Подписан на ивенты от микросериса юзеров через Rabbit. 2) Микросервис юзеров. Имеет 1 локальную базку с юзерами, их ролями, состоянием юзера и т.д. При блокировке юзеров - пуляет ивент в рэбит, чтобы oidc сервис потёр токены. 3) Публичный API, защищённый токенами для управления юзерами. Локальной базки не имеет. Обращается к oidc для валидации токенов, выполняет авторизацию запроса и, если всё ок - дёргает микросервис юзеров (по сути является шлюзом для него).

ну и важный момент - что именно тебе надо логировать.... а так - AOP тут хорошо ложится (или прокси классы)

Серега, это псевдокод. Там чуть подробнее нету смысла расписывать. Передаю на готовку я не готовое блюдо ))) Хочу логировать все внутри (дебаг: было столько ингредиентов, дебаг: осталось столько, еррор: хуясеты захотел, у тебя не хватает на складе итд) Поэтому прокси не прокатят. Да и, честно говоря, про AOP слышу в первые, с википедии не сильно понял что это. МОжно примерчик чуть пошире? Я так понял это просто пачка прокси-адаптеров?

Не. 3 микросервиса. 1) Oidc сервер. Имеет 1 локальную базку с выданными токенами и своими внутренними настройками (клиенты, клэймсы, скоупы - вот это всё). При аутентификации юзера он ходит к микросервису юзеров и запрашивает у него инфу. Подписан на ивенты от микросериса юзеров через Rabbit. 2) Микросервис юзеров. Имеет 1 локальную базку с юзерами, их ролями, состоянием юзера и т.д. При блокировке юзеров - пуляет ивент в рэбит, чтобы oidc сервис потёр токены. 3) Публичный API, защищённый токенами для управления юзерами. Локальной базки не имеет. Обращается к oidc для валидации токенов, выполняет авторизацию запроса и, если всё ок - дёргает микросервис юзеров (по сути является шлюзом для него).

хз хз... ну пусть так

а как блочить когда кто-то не заплатил?

Серега, это псевдокод. Там чуть подробнее нету смысла расписывать. Передаю на готовку я не готовое блюдо ))) Хочу логировать все внутри (дебаг: было столько ингредиентов, дебаг: осталось столько, еррор: хуясеты захотел, у тебя не хватает на складе итд) Поэтому прокси не прокатят. Да и, честно говоря, про AOP слышу в первые, с википедии не сильно понял что это. МОжно примерчик чуть пошире? Я так понял это просто пачка прокси-адаптеров?

AOP это те же прокси классы - возможность навесить хуки на вызов метода (до и после).

Серега, это псевдокод. Там чуть подробнее нету смысла расписывать. Передаю на готовку я не готовое блюдо ))) Хочу логировать все внутри (дебаг: было столько ингредиентов, дебаг: осталось столько, еррор: хуясеты захотел, у тебя не хватает на складе итд) Поэтому прокси не прокатят. Да и, честно говоря, про AOP слышу в первые, с википедии не сильно понял что это. МОжно примерчик чуть пошире? Я так понял это просто пачка прокси-адаптеров?

ну передавай логгер че))) либо у тебя должно быть что-то изолированное что распоряжается ингридиентами. Типа попросил ты "10 шампиньенов" и оно в лог написало что "у меня забрали" или "мне поступило"

а как блочить когда кто-то не заплатил?

Ну крутится таска на биллинге, и если кто-то не заплатил - она дергает микросервис юзеров, блокируя засранца, ну и дальше по цепочке.

ну передавай логгер че))) либо у тебя должно быть что-то изолированное что распоряжается ингридиентами. Типа попросил ты "10 шампиньенов" и оно в лог написало что "у меня забрали" или "мне поступило"

Ну хз, ну ты прикинь, у меня целый граф доменных объектов, я буду логгер пробрасывать везде?.... не, не оч. Лучше я заюзаю уже какой статический фасад для логгера, хер с ним, с солидом :)

Ну хз, ну ты прикинь, у меня целый граф доменных объектов, я буду логгер пробрасывать везде?.... не, не оч. Лучше я заюзаю уже какой статический фасад для логгера, хер с ним, с солидом :)

Джава так 20 лет живет и ок не парятся.

Как именно? Через статический фасад, или прокидывая технические сервисы по вызовам?

а если евенты кидать?

а уже логер подписывается на них и логирует чо надо

Как именно? Через статический фасад, или прокидывая технические сервисы по вызовам?

Logger log = LogManager.getLogger(“name”); Статика как она есть.

Logger log = LogManager.getLogger(“name”); Статика как она есть.

это сервис локатор между прочим

а если евенты кидать?

Имхо это переусложнение

а если евенты кидать?

ивенты стоит кидать на то что важно а не на все подряд

это сервис локатор между прочим

Ну да внутри. Что не отменяет его статичности.

это сервис локатор между прочим

Это точно дерьмо, и точно не сервис локатор :) Монолог называет это registry Но так как это не бизнесс сервис или бизнесс объект то в принципе, норм. Главное сделать метод статическим, но чтобы в тестах им можно было пользоваться.

Это точно дерьмо, и точно не сервис локатор :) Монолог называет это registry Но так как это не бизнесс сервис или бизнесс объект то в принципе, норм. Главное сделать метод статическим, но чтобы в тестах им можно было пользоваться.

хз, у меня таких проблем небыло))

Кстати такой вопрос. Геттеры сеттеры. А если у меня геттеры публичные и только возвращают значение (т.е. только для чтения состояния), а сеттеры - приватные и вызываются только чтобы записать значение внутри методов доменных объхектов - такой подход - норм?

Язык C# если что.

Ну то бишь я могу у User'а получить Name, а вот изменить его - только через вызов user.ChangeName(newName);

При этом вызов геттера никогда никак не мутирует состояние.

@fes0r что скажешь на этот счёт?

Кстати такой вопрос. Геттеры сеттеры. А если у меня геттеры публичные и только возвращают значение (т.е. только для чтения состояния), а сеттеры - приватные и вызываются только чтобы записать значение внутри методов доменных объхектов - такой подход - норм?

Норм для простых вьюх и если ты геттеры только для них юзаешь

1. тогда зачем сеттеры 2. зависит от того как геттеры используются. Если результат фигурирует в условиях/логике - то что-то тут не так

При этом вызов геттера никогда никак не мутирует состояние.

да он и не может по определению мутировать)

как я понимаю

да он и не может по определению мутировать)

там выше обсуждали квантовое ООП когда наблюдатель влияет на результат

1. тогда зачем сеттеры 2. зависит от того как геттеры используются. Если результат фигурирует в условиях/логике - то что-то тут не так

Да, сеттеры не нужны)

1. тогда зачем сеттеры 2. зависит от того как геттеры используются. Если результат фигурирует в условиях/логике - то что-то тут не так

Чтобы ORM могла в них значения записать, когда объект из базы десериализует

1. тогда зачем сеттеры 2. зависит от того как геттеры используются. Если результат фигурирует в условиях/логике - то что-то тут не так

затем что бы полем не делать публичным

Чтобы ORM могла в них значения записать, когда объект из базы десериализует

в шарпах же есть рефлексия

в шарпах же есть рефлексия

Есть, но ORM работает либо в связке геттер-сеттер (даже если приватный, главное чтобы он был), либо в связке геттер=>_приватное поле

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

Да, сеттеры не нужны)

Помню вообще ахирел когда оттебя это првый раз услышал) А потом ты еще скзаал что гетеры тоже нежелательны, я подумал ты вообще кукухой поехал) А щас вот проникся))

затем что бы полем не делать публичным

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

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

это специфичные кейсы, их можно по всякому решать.

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

ну конечно )

Помню вообще ахирел когда оттебя это првый раз услышал) А потом ты еще скзаал что гетеры тоже нежелательны, я подумал ты вообще кукухой поехал) А щас вот проникся))

Дзен

Помню вообще ахирел когда оттебя это првый раз услышал) А потом ты еще скзаал что гетеры тоже нежелательны, я подумал ты вообще кукухой поехал) А щас вот проникся))

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

время на серваке я буду перемещать туда куда надо

или еще что-нибудь такое

время на серваке я буду перемещать туда куда надо

мммм... типа того.

ну да