Привет, есть эндпоинт GET /api/user/{id}, который возвращает инфу о юзере.

есть две роли superadmin и admin. доступ к этому эндпоинту есть у обеих ролей, но я не хочу показывать чувствуительную инфу, если ее запршивает чел с ролью admin. то есть предположим у меня дто User, там есть каике-то поля и поле phone. я не хочу это поле включать в ответ если за ним пришел чел admin. как я могу этого добиться? я нагуглил решение с кастомной аннотацией, она бы имела поле "roles" и вешать на нужные поля её, и @JsonFilter из Jackson. типа запилить кастомный BeanPropertyFilter, который бы там из контекста доставал объект Authentication и чекал его роли и в Jackson конфигу его добавить.
еще есть какие-то задумки через @PostFilter/@PostAuthorize , может какое-то правило интересное придумать можно через SPEL, которое бы отсеивало поля ненужные. в общем что можете подсказать?

Та сделай два инфо объекта с одним интерфейсом и всё.

не подходит. если 100 полей будет, 100 объектов делать

Шта.

100 и 101 поле. два объекта

ваш подход предполагает, что если у меня будет 100 разных полей, которые я хочу исключить в зависимости от роли, то мне придется делать объекты под них. мне это не для одного раза гнужно, у меня есть 50 дто, в них по 10-20 полей, и я в зависимости от роли хочу разные поля скрывать в разных дто

Сто полей у юзера? Идея в том, чтобы просто исключить нужные поля.

хуярь 1 к 1

Могут точно сказать что PostFilter точно нет, а postAuthorize даже не представляю как можно выбрать вариант выдачи в зависимости от роли

имел ввиду 100 полей, которые надо исключить. в разных комбианцияз причем

для каждой роли своя таблица с набором полей, к основной сущности 1 к 1

просто предположил. вроде правила там можно довольно гибкие писать через spel

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

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

Сделай тогда адаптер который будет из дао делать нужный тебе дто объект. В адаптере будет логика

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

ну так а как он нужный объект будет делать? это придется через if'ы там из секьюрити контекста доставать authentication и смотреть что за роль, и какие поля отсечь?

мне тогда 50 методов писать, для 50 дто

По роли будешь отдавать нужный формат. Но вообще тут вопрос архитектуры корявой.

а при чем тут архитектура? есть дто, есть поля, я хочу какие-то поля не отображать определнным ролям. ну и опять же, по роли определять, мне тогда придется для каждого дто делать отдельный маппер-метод

Зачем 50. У тебя все поля доступны из дао. Ты просто смотришь роль и делаешь дто объект только с разрешенными полями

Возможно тебе стоит сделать какой-то объект внутри юзера, который будет хранить все те поля, которые должны фильтроваться по роли. Типа UserDetails

А если у тебя будет 100 ролей, то всё равно всем прописывать, к каким полям доступ давать А тут разницы я уже не вижу

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

Кхм. Ты объект из репы используешь на фронте?

ну, подход с кастомной аннотацией позволяет это довольно удобно сделать. у нее будет поле – список ролей, если появились какие-то изменения, например теперь надо номер отображть для роли admin, то я просто внесу его в аннотацию. ну примерно так это будет выгялдеть class User { @Visability(roles = {superadmin, admin} String phone; }

нет, я прямо противположное сказал. я говорю что в сервисе формируется дто, и я отдаю дто, я не сущность.

Сложно писать, возможно мы не понимаем друг друга. Или говорим об одном и том же. Суть в том, что с репы приходит юзер со всеми доступными полями. А для фронта делаются инфо Объекты(кто-то их называет дто, у меня на работе например это инфо объекты) с разными полями в зависимости от роли

ну этот момент я понял. ну так мне например надо возвращать 50 разных дто (инфо объектов). вы мне гвоорите мол "ну сделай адаптер (или маппер как я понял) который будет формировать нужный дто в зависимости от роли". ну так мне тогда на каждое дто нужен свой маппер

Да, маппер. У тебя реально что ли там так много ролей?

Как в итоге решил проблему?

На уровне сериализации буду отсеивать нужные поля. Определил кастомный json filter provider