java - 关于Spring Data JPA Rest(JpaRepository)的安全性问题

Question

我正在（尝试:)在Spring Boot应用程序中使用spring-boot-starter-data-rest通过真实的，成熟的restFULL api快速提供模型服务。很好。

问题1（安全性）：

Spring JpaRepository的优点是我不需要编写基本功能（save，findAll等）。是否可以在不覆盖所有自动实现方法的情况下保护这些自动实现的方法（浪费了Spring为我提供的功能）？即：

public interface BookRepository extends JpaRepository<Book, Long> {

    @PreAuthorize("hasRole('ROLE_ADMIN')")
    <S extends Book> Book save(Book book);
}

。

问题2（安全性）：

如何保护JpaRepository以防止更新登录用户不是所有者的项目？
即：仅允许用户修改自己的属性。
即2：只允许用户修改/删除他/她创建的帖子。
示例代码在这里非常受欢迎。

。

问题3（DTO）：

不久前，我与一个开发人员朋友发生了争执：他暗示必须从Spring MVC控制器返回DTO。即使DTO是模型对象的1-1副本。然后，我重新安排了工作，问其他人并确认了这一点：要求DTO划分/隔离应用程序层。

这与JpaRepositories有何关系？如何在Spring Auto Serverd Rest Repos中使用DTO？我应该完全使用DTO吗？

感谢您的提前提示/回答！

Answer 1

问题1：安全性

一些old docs提到：


  [...]您向不受您控制的客户端公开了一组预定义的操作，直到现在几乎全部还是全部。似乎没有办法只公开读取操作，而完全隐藏状态更改操作。


这意味着所有方法都是自动继承的（也按照标准java继承行为）。

根据@PreAuhtorize文档，您还可以将注释放置在类/接口声明上。

因此，您只需一个基本接口即可扩展JpaRepository

@NoRepositoryBean // tell Spring not create instances of this one
@PreAuthorize("hasRole('ROLE_ADMIN')") // all methods will inherit this behavior
interface BaseRepository<T, ID extends Serializable> extends Repository<T, ID> {}

然后将您所有的 Repository扩展名 BaseRepository。

问题2：安全性

我将对此进行更概括的介绍。

为了正确地规范对应用程序中实体的访问并定义可以看到的内容，您应该始终将项目分成不同的层。

一个好的起点是：


layer-web（或表示层）：访问 layer-business，不能访问 db-layer。可以看到 DTO模型，但不能看到 DB models
layer-business（或业务层）：访问 db-layer，但不能访问 DAO
layer-db（或数据层）：转换 DTO -> DB model。持久化对象并提供查询结果


对于您而言，我认为正确的做法是在请求甚至到达 layer-business类之前检查 Repository中的角色。

@Service
public interface BookService {

    @PreAuthorize("hasRole('ROLE_ADMIN')")
    ActionResult saveToDatabase(final BookDTO book);
}

或者，如前所述

@Service
@PreAuthorize("hasRole('ROLE_ADMIN')")
public interface BookService {

    ActionResult saveToDatabase(final BookDTO book);
}

同样，确保用户只能修改其自己的对象可以通过多种方式来完成。

正如 this answer指出的， Spring提供了所有必要的资源。

或者，如果您熟悉 AOP，则可以实现自己的逻辑。

例如（dummyCode）：

@Service
public interface BookService {
    // custom annotation here
    @RequireUserOwnership(allowAdmin = false)
    ActionResult saveToDatabase(final BookDTO book);
}

和检查：

public class EnsureUserOwnershipInterceptor implements MethodInterceptor {

    @Autowired
    private AuthenticationService authenticationService;

    @Override
    public Object invoke(Invocation invocation) throws Throwable {
        // 1. get the BookDTO argument from the invocation
        // 2. get the current user from the auth service
        // 3. ensure the owner ID and the current user ID match
        // ...
    }
}

关于 AOP的有用资源可以在 here和 here中找到。



问题3： DTO和 DB models


  我应该完全使用DTO吗？


是的，是的，你应该。即使您的项目只有几个模型，并且您只是出于娱乐目的而编程（仅在localhost上部署，学习等等）。

您越早养成分离模型的习惯，就越好。

同样，从概念上讲，一个是来自未知来源的对象，另一个是您数据库中的表。


  这与JpaRepositories有何关系？
  如何在Spring Auto Serverd Rest Repos中使用DTO？


现在就是重点！您不能将 DTO放入 @Repository中。您被迫将一个转换为另一个。同时，您还必须验证转换是否有效。

基本上，您要确保 DTO（脏数据）不会以任何方式接触数据库，并且要在数据库与应用程序的其余部分之间放置一堵由逻辑约束构成的墙。

我也知道 Spring与 model-conversion frameworks集成得很好。



那么， multi-layer / modular Web应用程序的优点是什么？


应用程序可以快速增长。特别是当您有许多开发人员在进行此工作时。一些开发人员倾向于寻找最快的解决方案并实施肮脏的技巧或更改访问修饰符以尽快完成工作。您应该强迫人们仅通过某些明确定义的渠道来访问某些资源。
从一开始设置的规则越多，遵循正确编程模式的时间就越长。不到一年，我已经看到银行申请变得一团糟。当需要 hotfix时，更改某些代码将创建另外两个bug。
您可能会达到应用程序占用过多OS资源的地步。假设您有一个 module-batch模块，其中包含应用程序的后台工作，则将其提取并将其实现到另一个应用程序中会更容易。如果您的模块包含查询数据库，访问任何类型的数据，为前端提供API的逻辑等等，那么您将基本上被迫将所有代码导出到新应用程序中。重构在那时将是脖子上的痛苦。
假设您想雇用一些数据库专家来分析您的应用程序执行的查询。使用定义明确且分离的逻辑，您可以仅使他们访问必需的 modules而不是整个应用程序。同样适用于前端自由职业者等。我也经历过这种情况。该公司希望数据库专家修复应用程序完成的查询，但不希望他们可以访问整个代码。最后，他们放弃了数据库优化，因为那样会使外部暴露太多敏感信息。


DTO / DB model分离的优点是什么？


DTO不会触及数据库。这为您提供了更高的安全性，可抵御来自外部的攻击
您可以决定另一方面。您的 DTO不需要将所有字段都实现为db模型。实际上，您甚至可以将 DAO映射到许多 DTO或相反。许多信息不应该到达前端，而使用 DTO可以轻松地做到这一点。
DTO通常比 @Entity型号高。实体被映射（例如 @OneToMany）到其他实体，而 DTO可能仅包含映射对象的id字段。
您不想让数据库对象闲逛太久；并且不会被您的应用程序的方法所传递。许多框架在每种方法的末尾提交数据库事务，这意味着对数据库实体进行的任何非自愿更改都可以提交给db。




我个人认为，任何有礼貌的Web应用程序都应将各个层严格分开，每个层都有其责任，并且对其他层的可见性有限。

数据库模型与数据传输对象之间的区别也是遵循的好模式。

最后，这只是我的意见；许多人认为 DTO模式已经过时，并导致不必要的代码重复。许多人认为，过多的分离倾向于难以维护代码。因此，您应该始终咨询不同的来源，然后应用最适合您的方法。

也很有趣：


SE: What is the point of using DTO (Data Transfer Objects)?
Lessons Learned: Don't Expose EF Entities to the Client Directly
Guice Tutorial – method interception（旧但金）
SO: Large Enterprise Java Application - Modularization
Microsoft Docs: Layered Application Guidelines
The 5-layer architecture