Size: a a a

2020 December 08

ДЗ

Динар Зарипов... in pro.jvm
Burevesnik 1960
https://pastebin.com/8Gn6gB0G
хай, что я не так делаю? хз уже который час ушел на эту проблему.
Есть основная сущность и логи ее изменений.
Нужно что бы при удалении основной удалились связанные логи.

mappedBy reference an unknown target entity property
В DataCollectionLogEntity должно быть поле с DataCollectionEntity. А в mappedBy укажи имя этого поля
источник

B1

Burevesnik 1960 in pro.jvm
Динар Зарипов
В DataCollectionLogEntity должно быть поле с DataCollectionEntity. А в mappedBy укажи имя этого поля
так и есть, хоть мне уже в лс помогли - спасибо за ответ
источник

П

Павел in pro.jvm
Что-то туплю. Сейчас в spring boot сервисе, есть spring security. Все работает. Но надо сделать проверку лицензии и не пускать если лицензия отсутствует. И хз куда эту проверку вставить. Представляю так, что это должен быть либо интерцептор либо фильтр. Причем вызываться должен он после того как секьюрити проверил пользователя и разрешил ему работать. В этом фильтре, интерцепторе, я достаю залогиненого пользователя, и иду в хранилищие за лицензией для него. Если нашел то все ок если нет то прервал цепочку и вернул ошибку. Но где этотвсетаки делать? В интерцепторе или в фильтре или еще где?
источник

IP

Iaroslav Postovalov in pro.jvm
Denis Chikanov
Простой вопрос: используются ли они только всем массивом (пройтись по всем и что-то (не) сделать), или по отдельности тоже?
Если второе - однозначно лучше поля.
А вообще звучит как вопрос для @javastart
в @javastart не занимаются микрооптимизациями, связанными с генерацией байт-кода в рантайме
источник

DC

Denis Chikanov in pro.jvm
Iaroslav Postovalov
в @javastart не занимаются микрооптимизациями, связанными с генерацией байт-кода в рантайме
Да, контекст не так понял сначала, пардон.
источник

PG

Pavel Glukhov in pro.jvm
Павел
Что-то туплю. Сейчас в spring boot сервисе, есть spring security. Все работает. Но надо сделать проверку лицензии и не пускать если лицензия отсутствует. И хз куда эту проверку вставить. Представляю так, что это должен быть либо интерцептор либо фильтр. Причем вызываться должен он после того как секьюрити проверил пользователя и разрешил ему работать. В этом фильтре, интерцепторе, я достаю залогиненого пользователя, и иду в хранилищие за лицензией для него. Если нашел то все ок если нет то прервал цепочку и вернул ошибку. Но где этотвсетаки делать? В интерцепторе или в фильтре или еще где?
а это у вас является частью аутентификационного процесса?
источник

PG

Pavel Glukhov in pro.jvm
т.е. без сертификата он аутентификацию не должен проходить. или сертификат нужен для авторизации?
источник

П

Павел in pro.jvm
Pavel Glukhov
а это у вас является частью аутентификационного процесса?
Можно так сказать. Сначала проверка что есть такой пользователь, потом проверка есть ли у него лицензия
источник

П

Павел in pro.jvm
Если юзера нет надо кинуть ошибку 403. Если все же пользователь есть но у него нет лицензии надо показать страничку мол чувак у тебя нет лицезии ты не можешь пользоваться сервисом
источник

П

Павел in pro.jvm
Стейтлес сервис,  на каждом запросе надо проверять
источник

П

Павел in pro.jvm
Выглядит так что нужен какой то интерцептор после секьюрити аутентификации но до вызова контроллера.
источник

PG

Pavel Glukhov in pro.jvm
я где-то год назад подобное делал, но там я решил в метод который дёргает UserDetailsServiceImpl добавил эту проверку.
он дёргается когда пользователь прошёл аутентификацию и по нему достаются данные и делаются остальные проверки.
источник

П

Павел in pro.jvm
Pavel Glukhov
я где-то год назад подобное делал, но там я решил в метод который дёргает UserDetailsServiceImpl добавил эту проверку.
он дёргается когда пользователь прошёл аутентификацию и по нему достаются данные и делаются остальные проверки.
Можно добавить проверку в аутентификейшен провайдер, который достает юзера и создает аутентификейшен токен, но это не очень. Тогда провайдер делает несколько отвественностей. Я уже делал подобное но забыл к чертям. Долдно быть типо

LicenseInterceptor 1
BlackListInterceptor 2
СанкцииInterceptor 3

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

П

Павел in pro.jvm
В каком то случае нужно вызвать проверку до секьюрити
источник

П

Павел in pro.jvm
Например кто-то фильтрует по айпи. Если айпи в блек листе, то сразу отбить запрос
источник

PG

Pavel Glukhov in pro.jvm
Павел
Можно добавить проверку в аутентификейшен провайдер, который достает юзера и создает аутентификейшен токен, но это не очень. Тогда провайдер делает несколько отвественностей. Я уже делал подобное но забыл к чертям. Долдно быть типо

LicenseInterceptor 1
BlackListInterceptor 2
СанкцииInterceptor 3

Типо запрос должен фильтроваться. Интерцепторы должны иметь порядок. В моем случае если пользователь успешно прошел секьюрити, должен вызваться следующий шаг проверки.
там можно ещё  для начала вызвать список всех фильтров. и может быть вашу проверку добавить на место какого-то.
@EnableWebSecurity(debug = true)
в некоторых случаях можно "занять" место неиспользуемого фильтра
источник

PG

Pavel Glukhov in pro.jvm
потом конечно (debug=true) убрать
источник

AE

Alexandr Emelyanov in pro.jvm
Gennady Moiseychenko
добрый день. используем у себя на проекте spring cloud: discovery(eureka) + gateway + микросервисы. Можно ли как-то настроить данную архитектуру, наверно  gateway или eureka, чтобы при получении 404 (допустим в одном из микросервисов есть функционал, а другой такой же еще не обновился) eureka и gateway  сами делали перезапрос на следующий сервис и конечному клиенту не приходилось делать это самому. Ну или еще ситуация. Сервис упал, а eureka еще не обновила его статус у себя. И часть запросов идет на сервис, которого уже нет. Спасибо
читайте про hystrix
источник

GM

Gennady Moiseychenko in pro.jvm
Alexandr Emelyanov
читайте про hystrix
спасибо
источник

A

Artjom Kalita in pro.jvm
Он деприкейтед же
источник