VG
неа. использую @Cacheable с data-redis
Size: a a a
2020 January 17
VG
Добрый день! Само собой, что на клиент нужно отдавать не Entity, а DTO. Обратите внимание на Modelmapper для маппинга. Если отдавать Entity ещё и со связями OneToMany ManyToOne, то Jackson ругается. Можно конечно это обойти (см. аннотацию @ Jsonİgnore)
кстати, про modelMapper... Для каждой модели создавать свой бин маппинга же?
OH
Господа, такой вопрос... Совсем недавно решил создать мультиязычный сайт на Spring Boot, с хранение данных в БД. Изучил кучу разных подходов и так и не нашёл варианта, который удовлетворил бы полностью меня. Набросал небольшой демо проект со своей реализацией для наглядности. . Что вы думаете об этом? Хотелось бы услышать мнение профессионалов. https://github.com/azerphoenix/spring-i18n-demo
OH
кстати, про modelMapper... Для каждой модели создавать свой бин маппинга же?
Нет, бин создаётся один.
VG
с переводами есть возможность выбрать подход: хранить переводы для всех сущностей в одной таблице, хранить переводы для каждой сущности в своей таблице.
Я бы предпочел второй. Чуть больше классов, написать сервис применения переводов (то есть найти сущность, найти ее переводы, заменить переводимые поля из переводов)
Я бы предпочел второй. Чуть больше классов, написать сервис применения переводов (то есть найти сущность, найти ее переводы, заменить переводимые поля из переводов)
VG
есть News (id, title, descr). есть NewsTranslation(locale, title, descr). Либо еще Можно совместить в одном News (id, locale, title, descr)
OH
с переводами есть возможность выбрать подход: хранить переводы для всех сущностей в одной таблице, хранить переводы для каждой сущности в своей таблице.
Я бы предпочел второй. Чуть больше классов, написать сервис применения переводов (то есть найти сущность, найти ее переводы, заменить переводимые поля из переводов)
Я бы предпочел второй. Чуть больше классов, написать сервис применения переводов (то есть найти сущность, найти ее переводы, заменить переводимые поля из переводов)
Благодарю! Да, действительно есть вариант с хранением переводов в отдельной таблице. Я лично выбрал возможность хранения переводом сущностей в самих таблицах без создания отдельных сущностей. Отличие доп. параметр (колонка) language, которая связана с @oneToMany ManyToOne с сущностью Language.
OH
И отдельно есть таблица translations (сущность Translation), которая хранит в себе переводы строк шаблона и т.д., которые потом интегрирую в шаблонизатор thymeleaf.
OH
Собственно говоря, в демо проекте есть пример реализации...
VG
Да, видел. Разные подходы для разных целей
OH
Да, видел. Разные подходы для разных целей
Согласен.
2020 January 18
PA
Вопрос по прикладному контролю прав доступа. Есть REST API с сервисами работы с деревом каталогов, доступ ролей пользователей к сервисам настроен через websecurityconfig. Но, нужно дополнительно контролировать права пользователей на уровне каталогов (т.е., грубо, сервис (endpoint) пользователю доступен, но не со всеми параметрами). Есть в спринге какие-либо готовые решения, подходы для этого?
K
Как вариант вынести контролируемый функционал в отдельный метод и повесить @RolesAllowed/@Secured
DM
Pavel Artyomenko
Вопрос по прикладному контролю прав доступа. Есть REST API с сервисами работы с деревом каталогов, доступ ролей пользователей к сервисам настроен через websecurityconfig. Но, нужно дополнительно контролировать права пользователей на уровне каталогов (т.е., грубо, сервис (endpoint) пользователю доступен, но не со всеми параметрами). Есть в спринге какие-либо готовые решения, подходы для этого?
Есть аннотации PreAuthorize и PostAuthorize, их можно ставить как на ендпоинты в контроллере, так и на методы слоев фасада/сервиса. Или ты не совсем об этом?
PA
Мне нужно проверить по параметрам (id каталога, например) что пользователь имеет право выполнять над ним действие.
PA
Можно конечно логику в фильтр запихать, по url проверять в какой сервис ломятся, а по параметрам права контролировать
DM
Pavel Artyomenko
Мне нужно проверить по параметрам (id каталога, например) что пользователь имеет право выполнять над ним действие.
Мне кажется, что можно пользователю отдавать только те каталоги, которые ему доступны. А если всё же хочется увеличить безопасность - не знаю метода проще, сделать на беке просто дополнительную проверку на то, доступен ли юзера каталог или нет
RS
@PreAuthorize поддерживает кастомные выражения.
Посмотрите SecurityExpressionOperations и его методы.
В т.ч. и hasPermission - это как раз о том, что вам нужно.
И это все описано в референс по секьюрити.
Туда можно и своих методов добавить, если нужно.
Посмотрите SecurityExpressionOperations и его методы.
В т.ч. и hasPermission - это как раз о том, что вам нужно.
И это все описано в референс по секьюрити.
Туда можно и своих методов добавить, если нужно.
PA
Ок, спасибо
RS
Если вкратце, то нужно написать свою имплементацию интерфейса PermissionEvaluator, в которой может быть любая логика. Например, проверяющая, разрешено ли текущему Authentication делать некое действие с неким энтити, у которой некий ID (это все параметры метода hasPermission).