Как правильно защитить свои конечные точки отдыха в jhipster?

Question

Я бы хотел сохранить свои конечные точки отдыха в бэкэнде.Например, автор может запросить свои книги следующим образом:

/ books? AuthorId = 5 & login = username

@GetMapping("/books")
@Timed
public ResponseEntity<List<Book>> getAllBooks(
        @RequestParam(value="authorId", required = false) String authorId, 
        @RequestParam(value="login", required = false) String login) {
    if(!login.equals(SecurityUtils.getCurrentUserLogin().get())){
        return ResponseEntity.status(401).build();
    }
    List<Book> result;
    if(authorId!= null)
        result = bookService.findByAuthorId(authorId);
    else if("admin".equals(SecurityUtils.getCurrentUserLogin().get()))
        result = bookService.findAll();
    else return ResponseEntity.status(401).build();
    return ResponseEntity.ok().body(result);
}

Желательно, чтобы я только передавал authorId впараметры

/ books? authorId = 5

, но так как SecurityUtils дает мне только loginName, я не могу их сравнить и идентифицировать пользователя в бэкэнде.

Кроме того, поскольку это микросервис, я не могу получить доступ к AccountService.java, который обрабатывается шлюзом.

Все отлично работает, но, кажется, неправильно?Есть ли лучший способ разрешить определенные запросы только для определенных пользователей?Должен ли я создать другую конечную точку отдыха, которая обрабатывает запросы на получение книг для конкретных пользователей?

Спасибо

Answer 1

Вы рассматриваете 2 варианта использования: один для авторов (список моих книг) и один для руководства (список всех книг) из соображений безопасности, но обычно вы также можете захотеть вернуть разные данные в зависимости от варианта использования.Было бы неплохо иметь 2 разных ресурса: / api / my_books для авторов и / api / books для управления, вы даже можете использовать вложенные ресурсы.

Для возврата разных данных (также из соображений безопасности) выможно использовать опцию DTO в JHipster со служебным слоем для сопоставления их с сущностями, а не для представления сущностей в ваших контроллерах REST.

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