在 Spring Boot Data REST 中进行实体验证后运行 @HandleBeforeCreate

Question

我正在使用 Spring Boot Data REST 来持久化我的 User 实体

@Entity
public class User {

    @Id
    @GeneratedValue
    private long id;

    @NotEmpty
    private String firstName;

    @NotEmpty
    private String lastName;

    @NotEmpty
    private String email;

    @Size(min = 5, max = 20)
    private String password;

    // getters and setters
}

使用存储库：

public interface UserRepository extends CrudRepository<User, Long> {}

我要做的是首先验证POSTed 用户：

@Configuration
public class CustomRestConfiguration extends SpringBootRepositoryRestMvcConfiguration {

    @Autowired
    private Validator validator;

    @Override
    protected void configureValidatingRepositoryEventListener(ValidatingRepositoryEventListener validatingListener) {
        validatingListener.addValidator("beforeCreate", validator);
    }

}

只有在将用户密码存储到数据库之前对其进行哈希处理：

@Component
@RepositoryEventHandler(User.class)
public class UserRepositoryEventHandler {

    private PasswordEncoder passwordEncoder = new BCryptPasswordEncoder();

    @HandleBeforeCreate
    public void handleUserCreate(User user) {
         user.setPassword(passwordEncoder.encode(user.getPassword()));
    }
}

但事实证明，验证是在密码散列之后执行的，因此由于 散列 密码太长而失败。

有什么方法可以指示 Spring 先执行验证，然后才对密码进行哈希处理？我知道我可以自己编写一个控制器并以细粒度的方式指定所有内容，但我宁愿把它作为最后的手段。

Answer 1

我在调试器中进行了调查，结果发现传入的实体按以下顺序处理：

1. Spring 在反序列化 SpringValidatorAdapter::validate 中的 JSON 时执行 bean 验证。这里的密码是纯文本的。
2. 调用@HandleBeforeCreate 并对密码进行哈希处理。
3. JPA 在将实体保存到数据库之前执行实体验证。这里的密码已经散列，验证失败。就我而言（JPA 的 Hibernate 实现），验证是在 BeanValidationEventListener::validate 中执行的。

解决方案 1（两个阶段的全面验证）

我发现的一个解决方案是通过仅使用 @NotEmpty 来放松对 password 字段的约束（这样两个验证阶段都通过了，并且仍然检查传入的 JSON 是否为空/无效）并执行@HandleBeforeCreate 中的原始密码（并在需要时从那里抛出适当的异常）。

这个解决方案的问题是它需要我编写自己的异常处理程序。为了跟上 Spring Data REST 设置的关于错误响应主体的高标准，我必须为这个简单的案例编写大量代码。执行此操作的方法描述为here。

解决方案 2（没有 JPA 实体验证的 Spring bean 验证）

正如Bohuslav Burghardt 所暗示的，可以禁用 JPA 完成的第二个验证阶段。这样，您可以保持最小和最大约束，同时避免编写任何额外的代码。与往常一样，这是简单性和安全性之间的权衡。 here 描述了禁用 JPA 的方法。

解决方案 3（仅保留最小密码长度限制）

另一个解决方案，至少在我的情况下是有效的，是让最大密码长度不受限制。这样，在第一个验证阶段，检查密码是否太短，在第二个阶段，它每次都有效地验证（因为加密的密码已经足够长了）。

这个解决方案的唯一警告是@Size(min = 5) 似乎不检查无效所以我不得不添加@NotNull 来处理这种情况。总而言之，该字段注释为：

@NotNull
@Size(min = 5)
private String password;