表单访问控制需依赖后端权限验证与数据过滤，前端控制仅作辅助。核心是通过RBAC等权限模型定义角色权限，后端在用户访问时校验权限，结合spring Security实现接口级控制，对敏感数据加密存储。前端禁用或隐藏字段不可靠，易被绕过，必须后端二次验证。复杂场景如行级权限，可通过mybatis拦截器动态修改sql添加过滤条件，或使用数据库视图、RLS框架实现。
表单中的访问控制，本质上就是控制谁能看到什么，谁能修改什么。这不仅仅是前端的事情，更重要的是后端权限验证和数据过滤。单纯靠前端隐藏字段或者禁用按钮是靠不住的，黑客稍微懂点技术就能绕过去。
解决方案
实现表单访问控制的核心在于权限管理和数据过滤。
-
权限模型设计： 首先要设计一个权限模型，常见的有基于角色的访问控制（RBAC）。简单来说，就是给用户分配角色，角色拥有不同的权限。例如，一个“管理员”角色可以查看和修改所有表单数据，而一个“普通用户”角色只能查看和修改自己创建的数据。更复杂的模型可能涉及到基于属性的访问控制（ABAC），但这通常用于更复杂的场景。
-
后端权限验证： 当用户尝试访问表单或提交数据时，后端需要验证用户是否拥有相应的权限。这通常涉及到检查用户的角色、权限以及请求的数据是否符合权限规则。可以使用 spring security、Shiro 等权限框架，也可以自己编写权限验证逻辑。
-
数据过滤： 即便用户有权访问表单，也需要根据权限规则过滤数据，确保用户只能看到他们应该看到的数据。例如，如果用户只能查看自己创建的数据，那么后端需要过滤掉其他用户创建的数据。
-
前端配合： 前端可以根据后端返回的权限信息，动态地显示或隐藏表单字段，禁用按钮等。但这仅仅是辅助手段，不能作为唯一的安全措施。
副标题1： 前端权限控制有哪些常见的坑？如何避免？
前端权限控制最大的坑就是“信任客户端”。永远不要相信客户端发送过来的任何数据，包括用户角色、权限信息等。
常见的坑包括：
- 隐藏字段绕过： 仅仅通过 css 隐藏字段，用户可以通过开发者工具轻松地看到并修改这些字段。
- 禁用按钮绕过： 禁用按钮只能阻止用户的点击操作，但用户可以通过开发者工具修改 html 元素，重新启用按钮。
- 权限信息篡改： 用户可以通过修改 Cookie、LocalStorage 等方式篡改权限信息。
避免这些坑的方法是：
副标题2： 如何在 spring boot 中实现表单权限控制？
在 Spring Boot 中实现表单权限控制，可以使用 Spring Security。
-
添加 Spring Security 依赖： 在
pom.xml
文件中添加 Spring Security 依赖。
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency>
-
配置 Spring Security： 创建一个配置类，继承
WebSecurityConfigurerAdapter
，并重写
configure(httpSecurity http)
方法，配置权限规则。
@Configuration @EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers("/admin/**").hasRole("ADMIN") // 只有 ADMIN 角色才能访问 /admin/** .antMatchers("/user/**").hasAnyRole("ADMIN", "USER") // ADMIN 和 USER 角色都能访问 /user/** .anyRequest().authenticated() // 其他请求需要认证 .and() .formLogin() // 使用表单登录 .permitAll() .and() .logout() .permitAll(); } @Autowired public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception { auth .inMemoryAuthentication() // 使用内存用户 .withUser("user").password("{noop}password").roles("USER") // {noop} 表示密码不加密 .and() .withUser("admin").password("{noop}password").roles("ADMIN"); } } -
在 Controller 中使用权限注解： 在 Controller 方法上使用
@PreAuthorize
注解，指定需要的权限。
@RestController public class UserController { @GetMapping("/user/profile") @PreAuthorize("hasRole('USER')") // 只有 USER 角色才能访问 public String getProfile() { return "User Profile"; } @GetMapping("/admin/dashboard") @PreAuthorize("hasRole('ADMIN')") // 只有 ADMIN 角色才能访问 public String getDashboard() { return "Admin Dashboard"; } }
副标题3： 如何处理复杂的权限逻辑，例如行级别权限控制？
对于复杂的权限逻辑，例如行级别权限控制（Row-Level Security, RLS），需要更精细的权限管理。
-
自定义权限表达式： Spring Security 提供了
PermissionEvaluator
接口，可以自定义权限表达式，实现更复杂的权限判断。
-
使用数据库视图： 可以创建数据库视图，根据用户的权限过滤数据。例如，创建一个只显示用户自己创建的数据的视图。
-
使用 ORM 框架的拦截器： 例如 MyBatis 的拦截器，可以在查询语句执行前修改 SQL，添加权限过滤条件。
-
使用专门的 RLS 框架： 例如 apache Ranger，可以提供更强大的 RLS 功能。
-
代码示例 (MyBatis 拦截器):
@Intercepts({@Signature( type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class} )}) public class DataPermissionInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { MappedStatement mappedStatement = (MappedStatement) invocation.getArgs()[0]; Object parameter = invocation.getArgs()[1]; // 获取当前用户信息（假设从 SecurityContextHolder 中获取） User user = (User) SecurityContextHolder.getContext().getAuthentication().getPrincipal(); // 根据用户角色和权限，修改 SQL 语句 String originalSql = mappedStatement.getBoundSql(parameter).getSql(); String modifiedSql = originalSql + " WHERE create_user = '" + user.getUsername() + "'"; // 创建新的 BoundSql 对象 BoundSql boundSql = new BoundSql(mappedStatement.getConfiguration(), modifiedSql, mappedStatement.getBoundSql(parameter).getParameterMappings(), parameter); // 创建新的 MappedStatement 对象 MappedStatement newMappedStatement = newMappedStatement(mappedStatement, boundSql); // 修改 invocation 的参数 invocation.getArgs()[0] = newMappedStatement; return invocation.proceed(); } // ... (省略 newMappedStatement 方法) }注意： 这个 MyBatis 拦截器只是一个简单的示例，实际应用中需要根据具体的业务逻辑和权限模型进行修改。例如，需要处理不同类型的 SQL 语句，处理复杂的权限规则，等等。 另外，直接在 SQL 语句中拼接用户 ID 可能存在 SQL 注入的风险，需要注意进行参数化处理。
权限控制是一个复杂的问题，需要根据具体的业务场景和安全需求选择合适的解决方案。
