文章目录
OverView
即使只限定在“软件架构设计”这个语境下，系统安全仍然是一个很大的话题。
接下来我们将对系统安全架构的各个方面进行详细分析，包括认证、授权、凭证、保密、传输安全和验证，结合案例实践，展示如何应用这些安全原则和技术，讨论具体解决方案和行业标准 ，并提供与业界标准相一致的解决方案。
计划：
-
认证（Authentication）：
- 介绍认证的基本概念及其在软件架构中的作用。
- 讨论常见的认证方法（如用户名/密码、双因素认证、生物识别）及其实现方式。
- 探讨行业标准和最佳实践（如 OAuth、OpenID Connect）。
-
授权（Authorization）：
- 定义授权的概念及其重要性。
- 讲解不同的授权模型（如基于角色的访问控制RBAC、基于属性的访问控制ABAC）。
- 介绍如何在架构中实现这些模型以及如何处理权限管理。
-
凭证（Credential）：
- 阐明凭证的作用及其管理方式。
- 讨论如何确保证书和凭证的真实性、完整性和不可抵赖性。
- 介绍现有的凭证管理方案和技术（如 PKI、公钥基础设施）。
-
保密（Confidentiality）：
- 解释数据保密的基本概念及其在系统中的应用。
- 讨论数据加密的技术和策略（如对称加密、非对称加密）。
- 介绍如何确保保密性，包括数据存储和处理中的加密措施。
-
传输（Transport Security）：
- 定义传输安全及其对系统安全的影响。
- 讲解如何实现传输层安全（如 TLS/SSL）的具体方法。
- 讨论如何保护网络通信免受中间人攻击和数据篡改。
导图
专家：软件开发 > 数据验证专家
要求：对数据验证的全面分析，包括最佳实践、常见问题和解决方案，重点讨论 Java 中的 Bean Validation
计划：
1. 引言：数据验证的重要性概述
数据验证不仅是确保用户输入正确性的手段，也是维护系统稳定性、数据一致性和安全性的重要措施。
2. 数据验证的基本概念
数据验证是指在数据被处理或存储之前，对其进行检查以确保数据符合预定义的规则。验证可以包括：
3. 数据验证的层次
前端验证
前端验证通常通过JavaScript进行，能够提供即时反馈，减少无效请求。这种验证可以捕捉一些基本错误，但并不足以替代后端验证。
后端验证
后端验证是确保数据在被处理前进行全面检查的关键。它可以防止不合法的数据通过API提交到服务器，并对业务逻辑进行严格控制。
4. 数据验证的标准做法
在Java中，采用Java Bean Validation（JSR 380）是进行数据验证的标准方法。该规范支持一系列内置的校验注解，如@NotNull、@Email、@Size等。
- 注解驱动：通过在Bean类的属性上使用注解定义校验规则。
- 统一管理：所有校验逻辑集中于Bean中，便于管理和维护。
5. 自定义校验注解
当内置注解无法满足业务需求时，可以自定义校验注解。例如，在用户注册中，需要确保用户名的唯一性。
与业务相关的校验往往才是最复杂的校验，将简单的校验交给 Bean Validation，而把复杂的校验留给自己，这简直是买椟还珠故事的程序员版本。其实以 Bean Validation 的标准方式来做业务校验是非常优雅的
/**
* 创建新的用户
*/
@POST
public Response createUser(@Valid @UniqueAccount Account user) {
return CommonResponse.op(() -> service.createAccount(user));
}
/**
* 更新用户信息
*/
@PUT
@CacheEvict(key = "#user.username")
public Response updateUser(@Valid @AuthenticatedAccount @NotConflictAccount Account user) {
return CommonResponse.op(() -> service.updateAccount(user));
}
注意其中的三个自定义校验注解，它们的含义分别是：
@UniqueAccount：传入的用户对象必须是唯一的，不与数据库中任何已有用户的名称、手机、邮箱产生重复。@AuthenticatedAccount：传入的用户对象必须与当前登录的用户一致。@NotConflictAccount：传入的用户对象中的信息与其他用户是无冲突的，譬如将一个注册用户的邮箱，修改成与另外一个已存在的注册用户一致的值，这便是冲突。
这里的需求很容易理解，注册新用户时，应约束不与任何已有用户的关键信息重复；而修改自己的信息时，只能与自己的信息重复，而且只能修改当前登录用户的信息。这些约束规则不仅仅为这两个方法服务，它们可能会在用户资源中的其他入口被使用到，乃至在其他分层的代码中被使用到，在 Bean 上做校验就能一揽子地覆盖上述这些使用场景。下
下面代码是这三个自定义注解对应校验器的实现类
public static class AuthenticatedAccountValidator extends AccountValidation<AuthenticatedAccount> {
public void initialize(AuthenticatedAccount constraintAnnotation) {
predicate = c -> {
AuthenticAccount loginUser = (AuthenticAccount) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
return c.getId().equals(loginUser.getId());
};
}
}
public static class UniqueAccountValidator extends AccountValidation<UniqueAccount> {
public void initialize(UniqueAccount constraintAnnotation) {
predicate = c -> !repository.existsByUsernameOrEmailOrTelephone(c.getUsername(), c.getEmail(), c.getTelephone());
}
}
public static class NotConflictAccountValidator extends AccountValidation<NotConflictAccount> {
public void initialize(NotConflictAccount constraintAnnotation) {
predicate = c -> {
Collection<Account> collection = repository.findByUsernameOrEmailOrTelephone(c.getUsername(), c.getEmail(), c.getTelephone());
// 将用户名、邮件、电话改成与现有完全不重复的，或者只与自己重复的，就不算冲突
return collection.isEmpty() || (collection.size() == 1 && collection.iterator().next().getId().equals(c.getId()));
};
}
}
这样业务校验便和业务逻辑就完全分离开来，在需要校验时用@Valid注解自动触发，或者通过代码手动触发执行，可根据你们项目的要求，将这些注解应用于控制器、服务层、持久层等任何层次的代码之中。此外，校验结果不满足时的提示信息，也便于统一处理，如提供默认值、提供国际化支持 、提供统一的客户端返回格式（创建一个用于ConstraintViolationException的异常处理器来实现.
对于 Bean 与 Bean 校验器，笔者另外有两条编码建议。第一条是对校验项预置好默认的提示信息，这样当校验不通过时用户能获得明确的修正提示，以下是代码示例：
/**
* 表示一个用户的信息是无冲突的
*
* “无冲突”是指该用户的敏感信息与其他用户不重合，譬如将一个注册用户的邮箱，修改成与另外一个已存在的注册用户一致的值，这便是冲突
**/
@Documented
@Retention(RUNTIME)
@Target({FIELD, METHOD, PARAMETER, TYPE})
@Constraint(validatedBy = AccountValidation.NotConflictAccountValidator.class)
public @interface NotConflictAccount {
String message() default "用户名称、邮箱、手机号码与现存用户产生重复";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
另外一条建议是将不带业务含义的格式校验注解放到 Bean 的类定义之上，将带业务逻辑的校验放到 Bean 的类定义的外面。这两者的区别是放在类定义中的注解能够自动运行，而放到类外面则需要像前面代码那样，明确标出注解时才会运行。譬如用户账号实体中的部分代码为：
public class Account extends BaseEntity {
@NotEmpty(message = "用户不允许为空")
private String username;
@NotEmpty(message = "用户姓名不允许为空")
private String name;
private String avatar;
@Pattern(regexp = "1\\d{10}", message = "手机号格式不正确")
private String telephone;
@Email(message = "邮箱格式不正确")
private String email;
}
这些校验注解都直接放在类定义中，每次执行校验的时候它们都会被运行。由于 Bean Validation 是 Java 的标准规范，它执行的频率可能比编写代码的程序所预想的要更高，譬如使用 Hibernate 来做持久化时，便会自动执行 Data Object 上的校验注解。对于那些不带业务含义的注解，运行是不需要其他外部资源参与的，不会调用远程服务、访问数据库，这种校验重复执行并没有什么成本。
但带业务逻辑的校验，通常就需要外部资源参与执行，这不仅仅是多消耗一点时间和运算资源的问题，由于很难保证依赖的每个服务都是幂等的，重复执行校验很可能会带来额外的副作用。因此应该放到外面让使用者自行判断是否要触发。
还有一些“需要触发一部分校验”的非典型情况，譬如“新增”操作 A 需要执行全部校验规则，“修改”操作 B 中希望不校验某个字段，“删除”操作 C 中希望改变某一条校验规则，这时候要就要启用分组校验来处理，设计一套“新增”、“修改”、“删除”这样的标识类，置入到校验注解的groups参数中去实现
6. 校验结果的处理
有效的校验结果处理是提升用户体验的关键。当校验失败时，系统应返回清晰的错误信息，指导用户进行修正。使用统一的异常处理机制可以实现这一点。
@ControllerAdvice
public class ValidationExceptionHandler {
@ExceptionHandler(ConstraintViolationException.class)
public ResponseEntity<Object> handleValidationException(ConstraintViolationException ex) {
// 返回错误信息
}
}
7. 性能考虑与副作用
在进行业务校验时，应注意校验的幂等性和性能。如果校验涉及到数据库查询，重复执行可能会引发不必要的性能开销或副作用。建议将格式验证放在Bean定义中，而将业务逻辑验证移至外部，以避免不必要的重复。
8. 小结
数据验证是软件开发中的一项基本而重要的任务。通过合理利用Java Bean Validation，结合自定义注解和统一处理机制，能够有效提高系统的稳定性与数据质量。
![[SAP ABAP] SELECTION-SCREEN](https://i-blog.csdnimg.cn/direct/19b16c13f3e44a51b33e9baec21744c3.png)
